Interesting! I will refrain from digging into QC right now, per Alan's
suggestion. :)
--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So
I studied with Jeffrey Hoffstein at Brown, one of the creators of NTRU. He
told me recently NTRU, which is lattice based, is one of the few (only?)
NIST-recommended QC-resistant algorithms.
We talked over layering on NTRU to Bitcoin last year when I was out that
way; I think such a thing could be
> > would make Ripple's consensus mechanism less attractive. People
> > talking about new scrypts harder to ASIC-mine when that's the elephant
> > in the room...
> > Sorry, I'm going off-topic.
> > SCIP-based merged mining for the win.
>
> SCIP is
You'll always lose a bit given by definition the maximum exchange
> >> rate is 1:1, but anonymity may be worth it. Others have written about
> >> cross-chain trading protocols, and I'll point out they are easier to
> >> implement if one chain has full visibility into what's happening on the
&
have warning if
someone wanted to try and spend them, and could do something about it. I'm
not sure if it gets me anything over a standard escrow arrangement, though.
Peter
--
--
[image: CoinLab Logo]PETER VESSENES
CEO
*pe...@coinlab.com * / 206.486.6856
amework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Are you
Maxwell
> wrote:
> > On Tue, Mar 12, 2013 at 11:09 AM, Gregory Maxwell
> wrote:
> >> On Tue, Mar 12, 2013 at 10:35 AM, Peter Vessenes
> wrote:
> >>> Can some enterprising soul determine if there were any double-spend
> attempts?
> >>> I'm
dev
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
--
[image: CoinLab Logo]PETER VESSENES
CEO
*pe...@coinlab.com
We've been toying with the idea of a 'dead' button, one that issues a bunch
of pre-generated txs sending stuff out to a previously secured 'backup' set
of addresses (we don't think in terms of wallets, just keypairs).
In this scenario, you have a long-term storage address (or set of them),
and if
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
--
[image: CoinLab Logo]PETER VESSENES
CEO
*pe...@coinlab.com * / 206.486.6856 / SKYPE: vessenes
811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104
My reply-all forward was blocked (over 40k), sigh. I figured I'd spammed
the list enough for one night.
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management
And, finally, when I say "Ditto to above" I mean "I have no idea", not
"nope". Double oops.
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know ex
I meant sent twice, a.
No double-spends that I'm aware of. Sorry for the loose verbiage!
Peter
On Tue, Oct 2, 2012 at 11:07 AM, Jeff Garzik wrote:
> On Tue, Oct 2, 2012 at 1:52 PM, Peter Vessenes wrote:
> > This is small, but an interesting tidbit from BTC Foundation payments;
Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-devel
--BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.17 (MingW32)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJQaaieAAoJEFvEB9dQFvtQUi0H/3Eh72DqxwBt6AeNos/hJNqQ
> ZowMNFRupJQM301EJ7SPQmcnVuc3RF2Jw//ckpAqdpkqhHCgGO9HX/q+Ic2A9erQ
> CfKbUOwQgqKuLQTZ8eT5UM
nfo.appdynamics.com/FreeJavaPerformanceDownload.html
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
--
[image: Co
This is a good idea. I think I can come up with the cash, I will
follow up with gavin.
Sent from my smartphone!
On Jul 29, 2012, at 7:18 PM, Mike Hearn wrote:
> MacOS X 10.8 makes application signing borderline mandatory, in that
> you cannot run unsigned apps unless you tweak your settings via
ty and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-d
ence
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/5012
On Fri, Jul 6, 2012 at 9:49 AM, Jeff Garzik wrote:
> On Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes wrote:
> > The proposal is simple, and it's a small change for miners, I imagine.
> >
> > My question is: why?
> >
> > I worry about stuffing too many r
Hi all,
I've been wondering about whether it would be possible to wipe out the GUI
completely from the satoshi client, and reimplement any necessary data
requests as RPC calls, allowing us to fork -QT and other GUIs over and
(hopefully) dramatically simplifying the codebase that you all have to wo
This is super cool!
I have a feature request: it would be awesome to be able to provide private
keys at the command line with the signature, turning the client into a
wallet-less signature machine.
Peter
On Thu, Jun 14, 2012 at 9:22 AM, Gavin Andresen wrote:
> I submitted a pull request yester
On Sat, Jun 2, 2012 at 8:52 PM, Luke-Jr wrote:
> Analysis, comments, constructive criticism, etc welcome for the following:
>
> ==Background==
> At present, an attacker can harm a pool by intentionally NOT submitting
> shares
> that are also valid blocks. All pools are vulnerable to this attack,
le for the 'maybes' to participate -- hence small
courtesies like allowing text/plain or text/html.
Peter
On Tue, May 29, 2012 at 11:18 AM, Luke-Jr wrote:
> On Tuesday, May 29, 2012 3:05:18 PM Peter Vessenes wrote:
> > 1) Germane to the original conversation, anything hard
nal requirements to the
protocol or codebase adds significant cost to the network as a whole over
the next 10 years.
Peter
On Tue, May 29, 2012 at 11:39 AM, Luke-Jr wrote:
> On Tuesday, May 29, 2012 3:36:34 PM Peter Vessenes wrote:
> > I suppose I mean that I don't understand how to rever
I suppose I mean that I don't understand how to reverse that into a URL
when one is presented only with a block, or perhaps a coinbase in a
transaction.
Best,
Peter
On Tue, May 29, 2012 at 11:34 AM, Luke-Jr wrote:
> On Tuesday, May 29, 2012 3:28:56 PM Peter Vessenes wrote:
>
OK, I have a few thoughts on this:
1) Germane to the original conversation, anything hard to implement will
not get implemented by miners.
2) Coinbase is hard-limited to 100 bytes; this has to include space for
voting as well as extra nonce, etc. So, I'm not sure that a full URL is a
good plan.
3)
One of the issues here though is that it would be nice if miners published
their own tx rules -- it might be hard to impute them from data.
I had started a thread about this on bitcoin.org some time ago, and I don't
recall what the general outcome was.
I had imagined an open service whereby a min
We just implemented our own mining tool, soup-to-nuts, and I would say that
the likely motivation for what I presume are botnet owners is just economic.
It's a lot more work to make sure your merkleing and keeping up-to-date are
happening than it is to just get an 80 byte header from a central ser
Thanks for this, Amir.
My initial reactions:
1) This is cool and useful (but see 3)
2) This is significantly less secure than validating an entire blockchain;
it's certainly worth working out some use cases here in more detail than
just a sample conversation. More on this below
3) What about disc
Blocks already checksum; they hash to a low number.
Also inre: block headers, you are furnished with a previous hash in the
first 80 bytes of the block. You can always cut the connection at that
moment if you've already seen the block headers.
Peter
On Mon, Apr 30, 2012 at 1:02 PM, Zell Faze w
These are interesting thoughts, karma for bitcoins essentially.
I would like CoinLab to publish a 'cost of subverting 1-n transactions with
90% probability' metric soon, and I think it would help everyone to
understand what that number is.
When we started out, you probably needed to wait 5 blocks
I agree that it would be nice if the protocol stayed stateless.
I also think we should try and keep in our heads the aggregate
bitcoin-universe cost of implementing any protocol change; even a very
small change, something that truly only takes one hour of time from each
bitcoin node client develop
I don't think it's minimally invasive to layer PGP's web of trust on top of
Bitcoin, in fact, the opposite.
>From a certain angle, bitcoin exists as a sort of answer / alternate
solution to the web of trust. Digital cash with an existing web of trust in
place was a working concept in the mid-1990s
This conversation reminds me that I'd like to see a comprehensive list of
tests that alt processors / generators can run against.
I haven't looked in the client code for some time, but does that exist now?
That would be a nice 'I want to help' early project, getting together
inputs and expected ou
It seems to me that the internet as a whole has got this one covered. I say
this as someone who thinks that BitCoin needs to choose its battles and
craft its reputation extremely carefully; this isn't the most important
fight for BitCoin, nor the most deadly.
I do think SOPA and PIPA could impact
36 matches
Mail list logo
