On Tue, Feb 18, 2014 at 02:14:24PM -0500, Ryan X. Charles wrote:
> The payment protocol is also the perfect opportunity to implement merge
> avoidance to increase customer and merchant privacy. The merchant can
> simply deliver multiple outputs in the payment details, say 10 or so,
> and the custom
On Tue, Feb 11, 2014 at 11:59:19AM -0600, Troy Benjegerdes wrote:
> Is there any code that does this? I would like to develop a multicoin-qt
> wallet that runs on two blockchains from one binary, and allows trading
> using this mechanism between the two chains.
Cross-chain trading is a different t
On Wed, Feb 12, 2014 at 08:34:48AM -0800, Dan Carter wrote:
> I'm not sure how well this would work.
>
> Sure it would provide honest historical pricing, but those who wait for
> publication confirmation may be at a disadvantage -- to get the best
> deal possible Bob would connect to as many nod
On Tue, Feb 11, 2014 at 01:00:21AM +0530, naman naman wrote:
> Hi guys,
>
> Please check this thread
> https://bitcointalk.org/index.php?topic=458608.0for a possible attack
> scenario.
>
> Already mailed Gavin, Mike Hearn and Adam about this :
>
> See if it makes sense.
That's basically what ap
On Sun, Feb 09, 2014 at 03:44:34PM -0500, Peter Todd wrote:
> On Sun, Feb 09, 2014 at 01:04:58PM -0500, Peter Todd wrote:
> > Alex Mizrahi recently outlined a mechanism(1) based on SIGHASH_SINGLE
> > that allows colored coins and similar embedded consensus system assets
>
On Mon, Feb 10, 2014 at 01:07:03PM -0600, Troy Benjegerdes wrote:
> If you've got any ideas for a better forum, let me know.
Your political conversations would be welcome at unsys...@lists.dyne.org
See you there.
--
'peter'[:-1]@petertodd.org
77ddbd0b6faa6d6fe50cdc7808dea5db5b538f85b736
On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:
> Hello all,
>
> it was something I planned to do since a long time, but with the
> recent related issues popping up, I finally got around to writing a
> BIP about how we can get rid of transaction malleability over time.
>
> The prop
On Sun, Feb 09, 2014 at 01:04:58PM -0500, Peter Todd wrote:
> Alex Mizrahi recently outlined a mechanism(1) based on SIGHASH_SINGLE
> that allows colored coins and similar embedded consensus system assets
> to be securely transferred to another party in exchange for Bitcoins
> at
On Sun, Feb 09, 2014 at 12:11:32PM -0600, Troy Benjegerdes wrote:
> On Sun, Feb 09, 2014 at 05:25:41PM +, Luke-Jr wrote:
> > On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote:
> > > We have an embedded consensus system and we want to be able to upgrade
>
On Sun, Feb 09, 2014 at 05:25:41PM +, Luke-Jr wrote:
> On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote:
> > We have an embedded consensus system and we want to be able to upgrade
> > it with new rules.
>
> This asserts a central authority and gives developers to
xout made the underlying change desired in the consensus state
atomically.
1) Alex Mizrahi, color kernel design considerations, Jan 7th 2014,
Colored coins (BitcoinX) mailing list,
https://groups.google.com/d/msg/bitcoinx/pON4XCIBeV4/IvzwkU8Vch0J
2) Peter Todd, [Bitcoin-development] Disentanglin
The Problem
===
We have an embedded consensus system and we want to be able to upgrade
it with new rules. There inevitably will be a transition period where
some users use clients that interpret the new rules, while others only
interpret the old rules. Since we only rely on the host consen
Thanks for the great response! I had about a dozen or so people contact
me with solutions for one or more questions, and even a anonymous
donation of 75mBTC to cover the rewards.
I'll start with my summaries of those solutions:
On Tue, Feb 04, 2014 at 08:03:13AM -0500, Peter Todd wrote:
>
On Tue, Feb 04, 2014 at 04:17:47PM +0100, Natanael wrote:
> Because it's trivial to create collisions! You can choose exactly what
> output you want. That's why XOR is a very bad digest scheme.
You're close, but not quite.
So, imagine you have a merkle tree, and you're trying to timestamp some
da
On Tue, Feb 04, 2014 at 09:43:31AM -0500, Jeff Garzik wrote:
> On Tue, Feb 4, 2014 at 8:17 AM, Peter Todd wrote:
> > Bonus question: What was I smoking? (hint: where do I live?)
>
> Cryptographers smoke... hash, right?
>
> (couldn't resist)
I think we have a winner
estamps-client/commit/288f3c17626974de7eaef4f1c9b5cd93eecf40f6
Why is that a bad idea?
Bonus question: What was I smoking? (hint: where do I live?)
> On Tue, Feb 4, 2014 at 2:03 PM, Peter Todd wrote:
>
> > On Tue, Feb 04, 2014 at 01:01:12PM +0100, Mike Hearn wrote:
> > > Hello,
> > >
> >
On Tue, Feb 04, 2014 at 01:01:12PM +0100, Mike Hearn wrote:
> Hello,
>
> I'm pleased to announce the release of bitcoinj 0.11, a library for writing
> Bitcoin applications that run on the JVM. BitcoinJ is widely used across the
> Bitcoin community; some users include Bitcoin Wallet for Android,
On Sun, Feb 02, 2014 at 01:16:20AM -0800, Jeremy Spilman wrote:
> >
> >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 que
> On Sat, Jan 25, 2014 at 05:19:01PM +0100, Adam Back wrote:
> [quote author=adam3us link=topic=431756.msg4729682#msg4729682
> date=1390660452]
> So have been talking with Greg Maxwell, Peter Todd, Jeremy Spillman,
> Mike Hearn, Bytecoin and others about reusable addresses.
>
&g
dependent, parties. The forum is not - as an example
archive.org didn't have that URL until I manually told it to archive it.
So I'm taking the liberty of reposting your two posts there below:
[quote author=adam3us link=topic=431756.msg4729682#msg4729682
date=1390660452]
So have bee
On Tue, Jan 28, 2014 at 06:33:28PM +0100, Mike Hearn wrote:
> In practice this should only be an issue if a payment is submitted and
> fails, which should be rare. Barring internal server errors and screwups on
> the merchants side, the only reasons for a rejection at submit time would
> be the imp
On Tue, Jan 28, 2014 at 07:53:14AM -0500, Gavin Andresen wrote:
> On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn wrote:
>
> > Yeah, that's the interpretation I think we should go with for now. There
> > was a reason why this isn't specified and I forgot what it was - some
> > inability to come to ag
On Fri, Jan 24, 2014 at 04:42:35PM +0100, Adam Back wrote:
> I think prefix has analysis side effects. There are (at least) 4 things
> that link payments: the graph of payment flows, timing, precise amounts, IP
> addresses, but with prefix a 5th: the prefix allows public elmination of
> candidates
On Fri, Jan 24, 2014 at 12:26:19PM +, Mike Hearn wrote:
> >
> > brittleness. The real world experience is that users, or to be exact
> > wallet authors, turn down SPV privacy parameters until bloom filters
> > have almost no privacy in exchange for little bandwidth usage.
>
>
> That's not fun
On Mon, Jan 20, 2014 at 08:00:05PM -0800, Jeremy Spilman wrote:
> Let's say the payee's reusable address is '
> ...', where is 2 bytes. Without any length indicator. What's the
> payer going to put on the blockchain? How would they know what the 'rest
> of the space' is? They would have t
On Tue, Jan 21, 2014 at 01:00:43AM +0100, Thomas Voegtlin wrote:
> Hi slush,
>
> Thank you for your new proposal; it seems to be a compromise.
>
> @Christophe Biocca:
> If the wordlist becomes part of the standard, then we will run into
> problems of collisions once users ask for wordlists in eve
On Wed, Jan 15, 2014 at 05:23:04PM -0800, Gregory Maxwell wrote:
> It also has a downside of not being indexable for the server, the
> server must do O(clients * reusable-address-txn) work and the work
> includes an ECC multiply.
>
> An idea that Adam Back had originally proposed was including opt
On Mon, Jan 20, 2014 at 04:05:14PM -0600, Brooks Boyd wrote:
> On Mon, Jan 20, 2014 at 11:42 AM, slush wrote:
>
> > Hi all,
> >
> > during recent months we've reconsidered all comments which we received
> > from the community about our BIP39 proposal and we tried to meet all
> > requirements for
On Sat, Jan 18, 2014 at 11:44:52AM -0600, Troy Benjegerdes wrote:
> > Ignoring prefixes the cost for each reusable address is only a small
> > percentage of the full node cost (rational: each transaction has one
> > or more ECDSA signatures, and the derivation is no more expensive), so
> > I would
On Sat, Jan 18, 2014 at 05:12:58PM -0600, Jeremy Spilman wrote:
>
>
> > 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.
> >
Finally seeing a more complex script-use-case being implemented:
http://www.coindesk.com/reality-keys-bitcoins-third-party-guarantor-contracts/
Enter Reality Keys, a new service by Tokyo-based startup Social
Minds due for public launch on 20th January. Reality Keys provides
real-world
On Fri, Jan 17, 2014 at 10:15:40AM +0100, Mike Hearn wrote:
> I must say, this shed is mighty fine looking. It'd be a great place to
> store our bikes. But, what colour should we paint it?
I think we should paint it this colour:
They had uncovered what seemed to be the side of a large coloure
On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote:
> 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 whi
On Tue, Jan 14, 2014 at 11:12:40AM -0800, Jeremy Spilman wrote:
> Maybe you are saying:
>
> byte[] S = EC.DH(e, Q2);
> byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S));
> byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S));
>
> But the payment would have (q2New - q1New) == (Q2 - Q1), s
On Mon, Jan 13, 2014 at 02:02:00PM -0800, Jeremy Spilman wrote:
>
> > 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
On Mon, Jan 13, 2014 at 01:13:08AM -0800, Jeremy Spilman wrote:
> It's a given this will be implemented for Payment Protocol. The question
> is whether it's also usable outside of PP.
I think what stealth addresses is showing is that the concept of an
address being "instructions on how to genera
On Mon, Jan 13, 2014 at 03:20:15PM -0800, Jeremy Spilman wrote:
> On Mon, 13 Jan 2014 13:27:52 -0800, Peter Todd wrote:
>
> >There is a catch however: if you need the prefix to be against
> >H(scriptPubKey) rather than scriptPubKey directly the sender needs to
> >grind t
On Mon, Jan 13, 2014 at 04:15:01PM -0500, Alan Reiner wrote:
> > I don't know if stealth addresses are the best solution to address
> > this use case, but AFAIK the only current solution to this use case is
> > to store a long-lived Bitcoin address in the addresss book.
> >
> > roy
> >
>
> Fair en
On Mon, Jan 13, 2014 at 12:10:56PM -0800, Gregory Maxwell wrote:
> 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 del
On Mon, Jan 13, 2014 at 02:59:08PM -0500, Alan Reiner wrote:
> How is this different from the proposal I have made?
>
> You distribute the root public key (but not chaincode!) of a BIP32
> branch. You can put your root key on a business card if you want. Then
> when someone wants to pay you, you
On Fri, Jan 10, 2014 at 01:29:03PM +0100, Jorge Timón wrote:
> On 1/10/14, Peter Todd wrote:
> > Situations where decentralized consensus systems are competing for
> > market share in some domain certainely apply. For instance if I were to
> > create a competitor to Nameco
On Fri, Jan 10, 2014 at 11:28:33AM +, Drak wrote:
> On 10 January 2014 10:20, Peter Todd wrote:
>
> > 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 communicatio
On Fri, Jan 10, 2014 at 06:11:28AM -0500, Peter Todd wrote:
> > Fair enough.
> > Do you see any case where an independently pow validated altcoin is
> > more secure than a merged mined one?
>
> Situations where decentralized consensus systems are competing for
>
On Thu, Jan 09, 2014 at 06:19:04PM +0100, Jorge Timón wrote:
> On 1/6/14, Peter Todd wrote:
> > On Sat, Jan 04, 2014 at 01:27:42AM +0100, Jorge Timón wrote:
> > It's not meant to prove anything - the proof-of-sacrificed-bitcoins
> > mentioned(*) in it is secure only i
On Wed, Jan 08, 2014 at 02:20:57AM -0800, Jeremy Spilman wrote:
> 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', correspond
On Tue, Jan 07, 2014 at 10:34:46PM -0800, Jeremy Spilman wrote:
> >
> >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
> > remaind
On Sun, Jan 05, 2014 at 07:43:58PM +0100, Thomas Voegtlin wrote:
> Hello and happy new year to this mailing list!
>
>
> Thank you Mark for the incredible work you've been doing on this.
> I am following this very closely, because it is of primary importance
> for Electrum.
>
> I have written a P
On Sat, Jan 04, 2014 at 01:27:42AM +0100, Jorge Timón wrote:
> > It's a thought experiment; read my original post on how to make a
> > zerocoin alt-chain and it might make more sense:
> >
> > http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html
> >
> > Even better mig
egory Maxwell, Dark Wallet Certification discussions, also
http://snowdenandthefuture.info/PartIII.html
3) Peter Todd, [Bitcoin-development] Privacy and blockchain data,
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03612.html
4) Bitcoin Wiki, Maximum transaction ra
* Summary
CoinJoin, CoinSwap and similar technologies improve your privacy by
making sure information about what coins you own doesn't make it into
the blockchain, but syncing your wallet is a privacy risk in itself and
can easily leak that same info. Here's an overview of that risk, how to
quanti
On Fri, Jan 03, 2014 at 08:14:25PM +0100, Jorge Timón wrote:
> > You assume the value of a crypto-currency is equal to all miners, it's
> > not.
>
> They should be able to sell the reward at similar prices in the market.
> Attackers are losing the opportunity cost of mining the currency by
> attac
On Fri, Jan 03, 2014 at 09:23:20PM +0100, Adam Back wrote:
> Seems like you (Nadav) are the third person to reinvent this idea so far :)
Lol, fourth if you include me, although my case is rather embarassing as
I had re-read Bytecoin's original post recently and completely missed
the main point of
On Wed, Jan 01, 2014 at 05:09:27AM +, Luke-Jr wrote:
> > You assume the value of a crypto-currency is equal to all miners, it's
> > not.
> >
> > Suppose I create a merge-mined Zerocoin implementation with a 1:1
> > BTC/ZTC exchange rate enforced by the software. You can't argue this is
> > a s
On Tue, Dec 31, 2013 at 01:14:05AM +, Luke-Jr wrote:
> On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote:
> > that you are using merge-mining is a red-flag because without majority, or
> > at least near-majority, hashing power an attacker can 51% attack your
> >
On Sun, Dec 29, 2013 at 11:53:19AM -0700, Evan Duffield wrote:
> Hello,
>
> We’re a startup looking for 1 or 2 really good C++ programmer that is
> familiar with the bitcoin internals to help with a for-profit startup.
>
> We will be able to provide more information about the project after signin
On Tue, Dec 24, 2013 at 12:52:46AM -0800, Jeremy Spilman wrote:
> 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 prob
trong censorship
resistance with strong consensus in a fixed amount of time.
1) Gregory Maxwell, [Bitcoin-development] To prevent arbitrary data
storage in txouts — The Ultimate Solution,
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg01987.html
2) Peter Todd, Re:
On Fri, Dec 20, 2013 at 03:21:38AM -0800, Mark Friedenbach wrote:
> Hi Jeremy, Let's give a preview of the application-oriented BIPs I
> mentioned:
>
> Stateless validation and mining involves prefixing transaction and
> block messages with proofs of their UTxO state changes. These are the
> "oper
On Fri, Dec 20, 2013 at 03:10:50AM -0800, Mark Friedenbach wrote:
> On 12/20/2013 02:48 AM, Peter Todd wrote:
> > On Thu, Dec 19, 2013 at 05:47:52PM -0800, Mark Friedenbach wrote:
> >> This BIP describes the authenticated prefix tree and its many
> >> variations
On Thu, Dec 19, 2013 at 05:47:52PM -0800, Mark Friedenbach wrote:
> This BIP describes the authenticated prefix tree and its many
> variations in terms of its serialized representation. Additional BIPs
> describe the application of authenticated prefix trees to such
> applications as committed indi
On Thu, Dec 19, 2013 at 04:04:17PM -, Amir Taaki wrote:
Looks like for this to actually go to the email lists they need to be in
the To: field.
> About signing each commit, Linus advises against it:
>
> http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html
>
> "Btw, ther
Here's my draft. I don't claim this to be "official", but I think this
should represent the consensus we've come to at the DarkWallet
Hackathon; I'm writing it up as an email in part to preserve a record of
that consensus.
* General Principles
We believe in decentralization, user-defined privacy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
So, vendors hat on, what would it take for, say, BitPay to implement merge
avoidance and coinjoin together?
At the dark wallet hackathon when we were talking usability we decided that the
main way to get coinjoin working well is to take advantage
On Wed, Dec 04, 2013 at 02:48:08PM +0100, Mike Hearn wrote:
> On Wed, Dec 4, 2013 at 2:06 PM, Peter Todd wrote:
>
> > replace-by-fee is no less speculative than your original proposals;
> > you're also trying to convince people that things should work
> > dif
On Wed, Dec 04, 2013 at 12:09:42PM +0100, Mike Hearn wrote:
> Please don't try and drag this thread off topic. What I said is factually
> correct. If you want to (again) try and convince people things should work
> differently, start another thread for that.
replace-by-fee is no less speculative t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mike Hearn wrote:
>I think this US/other cultural issue is complicating things more than
>we
>appreciate.
>
>I am trying to imagine in my head how all this will work and what it
>will
>look like with allow_fee, and I just can't see it. Merchants w
On Tue, Dec 03, 2013 at 12:57:23PM +0100, Taylor Gerring wrote:
>
> On Dec 3, 2013, at 12:29 PM, Mike Hearn wrote:
>
> > It may be acceptable that receivers don't always receive exactly what they
> > requested, at least for person-to-business transactions. For
> > person-to-person transaction
On Tue, Dec 03, 2013 at 12:29:03PM +0100, Mike Hearn wrote:
> On Tue, Dec 3, 2013 at 12:07 PM, Gavin Andresen
> wrote:
>
> > Making it fee-per-kilobyte is a bad idea, in my opinion; users don't care
> > how many kilobytes their transactions are, and they will just be confused
> > if they're payin
On Tue, Dec 03, 2013 at 11:09:51AM +, Drak wrote:
> On 3 December 2013 11:03, Peter Todd wrote:
>
> > UI once both are implemented is to not show anything in the default
> > case, and explain to the user why they have to pay extra in the unusual
> > case where they ar
On Sun, Dec 01, 2013 at 12:51:46PM +0100, Mike Hearn wrote:
> 4) Finally, when we next hard fork, we make v2 transactions include the
> output value in the signature, same as the output script (this proposal has
> been on the forums for a while now). That allows the fee data added in step
> 2 to be
On Tue, Dec 03, 2013 at 11:40:35AM +1000, Gavin Andresen wrote:
> On Tue, Dec 3, 2013 at 12:44 AM, Mike Hearn wrote:
>
> > PPv1 doesn't have any notion of fee unfortunately. I suppose it could be
> > added easily, but we also need to launch the existing feature set.
> >
>
> Lets bang out a merch
On Sun, Dec 01, 2013 at 07:18:07PM +0100, Mike Hearn wrote:
> > Bitcoin is and always will be limited in capacity - transactions may not
> > confirm in a reasonable about of time because of high-demand and/or DoS
> > attacks.
>
> I agree in the general case, but I was talking about the mobile wall
On Sun, Dec 01, 2013 at 06:19:14PM +0100, Mike Hearn wrote:
> > Both can be combined into adapting the current generic messages ("This
> > payment should become spendable shortly" for incoming and "This payment
> > has not been transmitted yet" for outgoing transactions).
>
> What would the new m
So Sarchar and I were talking about his Bitstorage scheme(1) and we came
to the conclusion that it wouldn't work. However he came up with a less
abitious idea that I thought would work: force people to prove they were
still holding your data D by publishing transactions with scriptPubKeys
of the fo
On Sun, Nov 24, 2013 at 05:20:22PM +0100, Christian Decker wrote:
> Since this came up again during the discussion of the Cornell paper I
> thought I'd dig up my measurement code from the Information
> Propagation paper and automate it as much as possible.
>
> The result is the Network Propagation
On Fri, Nov 15, 2013 at 02:19:56PM -0500, Peter Todd wrote:
> On Fri, Nov 15, 2013 at 12:47:46PM +0100, Michael Gronager wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 15/11/13, 11:32 , Peter Todd wrote:
> >
> > > alpha = (1
On Tue, Nov 19, 2013 at 05:32:55PM +0100, Wladimir wrote:
> On Mon, Oct 21, 2013 at 4:30 PM, Jeff Garzik wrote:
>
> > BIP drafts are stored in git://github.com/bitcoin/bips.git/drafts/ and
> > are not automatically assigned a BIPS number.
> >
>
> Are we going to move ahead with this?
>
> If so,
etric commitment for stronger byzantine voting resilience,
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02184.html,
Adam Back
5) Near-block broadcasts for proof of tx propagation,
http://www.mail-archive.com/bitcoin-deve
On Mon, Nov 04, 2013 at 11:11:34AM -0800, Mark Friedenbach wrote:
> > Now interpret the bits of that UUID as an allowed path: 0 = left, 1
> > = right, from the top of the tree. When you build the tree, make
> > sure everything that is going to be committed to uses it's allowed
> > path; the tree wi
On Fri, Nov 15, 2013 at 12:47:46PM +0100, Michael Gronager wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 15/11/13, 11:32 , Peter Todd wrote:
>
> > alpha = (1/113)*600s/134kBytes = 39.62uS/byte = 24kB/second
> >
> > Which is atrocious...
>
On Fri, Nov 15, 2013 at 12:58:14PM +0100, Michael Gronager wrote:
> My Q and q are meant differently, I agree to your Q vs Q-1 argument,
> but the q is "me as a miner" participating in "a pool" Q. If I
> participate in a pool I pay the pool owner a fraction, e, but at the
> same time I become part
On Fri, Nov 15, 2013 at 11:47:53AM +0100, Michael Gronager wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Peter,
>
> Love to see things put into formulas - nice work!
>
> Fully agree on the your fist section: As latency determines maximum
> block earnings, define a 0-latency (bi
On Thu, Nov 07, 2013 at 11:28:52AM -0700, Daniel Lidstrom wrote:
> Hey Peter, something seems wrong with your above analysis: I think a miner
> would withhold his block not because it leads to a greater probability of
> winning the next one, but because it increases his expected revenue.
>
> Suppo
On Thu, Nov 07, 2013 at 10:58:42PM +0100, Michael Gronager wrote:
> > Q=0-> f = 0.0033 BTC/kB Q=0.1 -> f = 0.0027 BTC/kB Q=0.25 -> f
> > = 0.0018 BTC/kB Q=0.40 -> f = 0.0012 BTC/kB
>
> You second list of numbers is an unlikely extreme:
>
> > k = 1mS/kB
>
> The propagation latency in the net
On Wed, Nov 13, 2013 at 01:34:07PM +0100, Michael Gronager wrote:
> Just a quick comment on the actual fees (checked at blockchain.info) the
> average fee over the last 90 days is actually ~0.0003BTC/txn - so not
> too far behind the theoretical minimum of 0.00037BTC/txn.
How did you get those num
On Wed, Nov 13, 2013 at 12:52:21PM +0100, Michael Gronager wrote:
> Last week I posted a writeup: "On the optimal block size and why
> transaction fees are 8 times too low (or transactions 8 times too big)".
>
> Peter Todd made some nice additions to it including different
On Wed, Nov 13, 2013 at 08:01:27PM +, John Dillon wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> > Last week I posted a writeup: "On the optimal block size and why
> > transaction fees are 8 times too low (or transactions 8 times too big)".
&g
> Final conclusions is that the fee currently is too small and that there
> is no need to keep a maximum block size, the fork probability will
> automatically provide an incentive to not let block grows into infinity.
Your definition of P_fork is inaccurate for a miner with non-negligable
hashing
On Thu, Nov 07, 2013 at 02:56:56PM +1000, Gavin Andresen wrote:
> > P.S: If any large pools want to try this stuff out, give me a shout. You
> > have my PGP key - confidentiality assured.
> >
>
> If I find out one of the large pools decides to run this 'experiment' on
> the main network, I will ma
On Wed, Nov 06, 2013 at 10:59:28PM -0600, Kyle Jerviss wrote:
> Each block that you solve has a reward. In practice, some blocks
> will be orphaned, so the expected reward is slightly less than the
> nominal reward. Each second that you delay publishing a block, the
> expected reward drops somewh
On Wed, Nov 06, 2013 at 10:15:40PM -0600, Kyle Jerviss wrote:
> You are ignoring the gambler's ruin. We do not operate on an
> infinite timeline. If you find a big pool willing to try this,
> please give me enough advance warning to get my popcorn ready.
Gamblers ruin has nothing to do with it.
On Wed, Nov 06, 2013 at 01:06:47PM -0500, Christophe Biocca wrote:
> I might try building this sometime soon. I think it may also serve an
> educational purpose when trying to understand the whole network's behaviour.
>
> What level of accuracy are we looking for though? Obviously we need to
> ful
On Tue, Nov 05, 2013 at 12:43:15PM -0500, Ittay wrote:
> On Tue, Nov 5, 2013 at 12:14 PM, Peter Todd wrote:
>
> > On Tue, Nov 05, 2013 at 12:05:41PM -0500, Peter Todd wrote:
> > > On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote:
> >
> > Oh, and I don&#x
On Tue, Nov 05, 2013 at 12:05:41PM -0500, Peter Todd wrote:
> On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote:
> > Hello,
> >
> > Please see below our BIP for raising the selfish mining threshold.
> > Looking forward to your comments.
>
>
>
>
On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote:
> Hello,
>
> Please see below our BIP for raising the selfish mining threshold.
> Looking forward to your comments.
> 2. No new vulnerabilities introduced:
> Currently the choice among equal-length chains is done arbitrarily,
> depending on
On Mon, Nov 04, 2013 at 08:14:37PM -0800, Gustaw Wieczorek wrote:
> Mike Hearn wrote:
>
> > how about if we wrote code to automatically build a miner backbone
>
> Yeah, let's build a backbone, or a cloud, and then we could have Google run
> it!
>
> Come on, Mike, your conflict-of-interest as an
On Mon, Nov 04, 2013 at 04:45:24PM -0500, Alan Reiner wrote:
> So given the assumption that Alice is "well-connected" as Peter
> mentioned, it seems like this is a concern. But is this a realistic
> assumption? All miners have an incentive to be thoroughly connected to
> one another, to make sure
On Mon, Nov 04, 2013 at 02:12:44PM -0500, Ittay wrote:
> On Mon, Nov 4, 2013 at 10:25 AM, Ittay wrote:
>
> > As for the rational motivation of the individual miners - that's a good
> > point!
> > Here is a solution we did not put in the paper due to space constraints
> > that should alleviate you
On Mon, Nov 04, 2013 at 01:16:49PM -0500, Peter Todd wrote:
> You'll want to put some "reasonable" limit on actual path lengths, just
> pick something like 32 levels; if applications pick their UUIDs honestly
> a collision will be very unlikely. You can also make the allowe
On Mon, Nov 04, 2013 at 01:00:16PM +0100, Mike Hearn wrote:
> Given that IP address data is inherently transient, perhaps a better
> solution is to define a short hash in the coinbase that commits to extra
> data that is relayed along with block data (e.g. appended to the block
> message). It can t
301 - 400 of 578 matches
Mail list logo
