On Thursday, May 15, 2014 11:50:29 AM Andreas Schildbach wrote:
> dnsseed.bitcoin.dashjr.orgSERVFAIL, tried multiple ISPs
FWIW, this may be a routing issue: I notice various ISPs have been unable to
route to my server over IPv4 today. IPv6 seems to be fine.
Not sure how important DNS
On Friday, May 16, 2014 5:17:17 PM Rob Golding wrote:
> > > dnsseed.bitcoin.dashjr.orgSERVFAIL, tried multiple ISPs
>
> dnsseed.bitcoin.dashjr.org. 60 IN NS jun.dashjr.org.
> but jun.dashjr.org isn't responding to dns queries (as at 18.10 GMT
> 2014-05-16)
>
> that woul
On Tuesday, June 03, 2014 4:29:55 AM xor wrote:
> Hi,
>
> I thought a lot about the worst case scenario of SHA256d being broken in a
> way which could be abused to
> A) reduce the work of mining a block by some significant amount
> B) reduce the work of mining a block to zero, i.e. allow instant m
On Friday, July 04, 2014 8:21:42 PM Jorge Timón wrote:
> On 7/4/14, kjj wrote:
> > I suspect that there exist no algorithms which cannot be done better in
> > an application-specific device than in a general purpose computer. And
> > if there is such a thing, then it must necessarily perform best
On Tuesday, July 15, 2014 8:00:41 AM Jeff Garzik wrote:
> Proxying another's idea, from CoinSummit.
>
> The request: It would be useful to limit the lifetime of a bitcoin
> address. Intentionally prevent (somehow) bitcoins being sent to a
> pubkey/pkh after the key expires.
>
> You could appen
On Tuesday, July 15, 2014 3:11:25 PM Jeff Garzik wrote:
> On Tue, Jul 15, 2014 at 10:48 AM, Luke Dashjr wrote:
> > They can already do this. It's perfectly valid for wallets/services to
> > ignore (and not consider as payment) transactions using an address more
> > than
On Thursday, August 07, 2014 11:02:21 PM Pedro Worcel wrote:
> Hi there,
>
> I was wondering if you guys have come across this article:
>
> http://www.wired.com/2014/08/isp-bitcoin-theft/
>
> The TL;DR is that somebody is abusing the BGP protocol to be in a position
> where they can intercept th
On Friday, August 08, 2014 12:29:31 AM slush wrote:
> AFAIK the only protection is SSL + certificate validation on client side.
> However certificate revocation and updates in miners are pain in the ass,
> that's why majority of pools (mine including) don't want to play with
> that...
Certificate
On Friday, August 08, 2014 6:21:18 PM Jeff Garzik wrote:
> gmaxwell noted on IRC that enabling TLS could be functionally, if not
> literally, a DoS on the pool servers. Hence the thought towards a
> more lightweight method that simply prevents client payout redirection
> + server impersonation.
M
On Saturday, August 23, 2014 6:44:15 PM Mike Hearn wrote:
> > Not to mention encrypting basically non-sensitive inter-node traffic is
> > almost completely worthless in providing anonymity anyway...
>
> Recall that P2P connections carry Bloom filters too, which are not public
> information.
As so
On Sunday, September 28, 2014 5:15:53 AM Peter Todd wrote:
> On Sat, Sep 27, 2014 at 07:55:44PM -0700, Tom Harding wrote:
> > On 9/25/2014 7:37 PM, Aaron Voisine wrote:
> > > Of course you wouldn't want nodes to propagate alerts without
> > > independently verifying them
> >
> > How would a node i
On Wednesday, October 01, 2014 1:08:26 PM Peter Todd wrote:
> I've written a reference implementation and BIP draft for a new opcode,
> CHECKLOCKTIMEVERIFY.
Thoughts on some way to have the stack item be incremented by the height at
which the scriptPubKey was in a block? A limitation of encoding
On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote:
> On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr wrote:
> >Thoughts on some way to have the stack item be incremented by the
> >height at
> >which the scriptPubKey was in a block?
>
> Better to create a
On Friday, October 03, 2014 2:28:17 PM Matt Whitlock wrote:
> Is there a reason why we can't have the new opcode simply replace the top
> stack item with the block height of the txout being redeemed? Then
> arbitrary logic could be implemented, including "output cannot be spent
> until a certain ti
On Sunday, October 12, 2014 8:41:29 AM Geir Harald Hansen wrote:
> On 12.10.2014 01:34, Pieter Wuille wrote:
> > * No orphan blocks stored in memory anymore (reducing memory usage during
> > sync).
>
> Will this slow down reorgs after a fork, compared to today?
It shouldn't... he's talking about
On Wednesday, October 15, 2014 8:47:18 AM Wladimir wrote:
> These BIPs should go to Final state - they are implemented all over
> the place, and are thus entirely fixed in place now. Any changes would
> require a new BIP as amandment:
>
> - BIP 14 (BIP Protocol Version and User Agent)
ACK
> - BI
On Wednesday, October 15, 2014 7:40:04 PM Peter Todd wrote:
> On Wed, Oct 15, 2014 at 08:00:10PM +0100, Btc Drak wrote:
> > > * Google lists are somehow a little proprietary or gmail lockin
> > > focused eg it makes things extra hard to subscribe with a non-google
> > > address if google has any hi
On Thursday, October 16, 2014 6:22:04 AM Wladimir wrote:
> > Shouldn't we be doing this in a GitHub PR rather than spamming up the ML?
>
> Not really. BIP changes should be discussed on the mailing list,
> that's the way to get community consensus (as specified in BIP1).
>
> Wladimir
Discussion
On Sunday, October 26, 2014 7:57:12 AM Wladimir wrote:
> Let me know if there is anything else you think is ready (and not too
> risky) to be in 0.10.
At the very least, we need:
#5106 Bugfix: submitblock: Use a temporary CValidationState to determine ...
#5103 CreateNewBlock and miner_tests:
On Sunday, November 16, 2014 4:21:27 PM Flavien Charlon wrote:
> The data that can be embedded as part of an OP_RETURN output is currently
> limited to 40 bytes. It was initially supposed to be 80 bytes, but got
> reduced to 40 before the 0.9 release to err on the side of caution.
>
> After 9 mont
Is anyone working on a serialisation format to convey P2SH HD chains? For
example, to give someone who wants to make recurring payments a single token
that can be used to generate many P2SH addresses paying to a multisig script.
I'm thinking of something along the lines of a simple series of tok
On Thursday, December 04, 2014 8:02:17 PM Jeffrey Paul wrote:
> What is the use case for something like this? It’s my impression that a
> single token that can be used to obtain many P2SH addresses paying to a
> multisig script looks something like
>
>bitcoin:?r=https://payee.com/customer1234
On Monday, December 29, 2014 7:21:02 PM Sergio Lerner wrote:
> I propose to allow miners to voluntarily lock funds by letting miners
> add additional inputs to the coinbase transaction. Currently the
> coinbase transaction does not allow any real input to be added (only a
> pseudo-input).
This is
On Monday, December 29, 2014 9:10:20 PM Mike Hearn wrote:
> How does adding inputs to a coinbase differ from just having pay-to-fee
> transactions in the block?
Pay-to-fee transactions can be "stolen" by another block at the same or
greater height. Additional inputs to the generation transaction
On Friday, February 06, 2015 3:16:13 AM Justus Ranvier wrote:
> On 02/04/2015 02:23 PM, Isidor Zeuner wrote:
> > Hi there,
> >
> > traditionally, the Bitcoin client strives to hide which output
> > addresses are change addresses going back to the payer. However,
> > especially with today's dynamic
Where is the Specification section?? Does this support arbitrary scripts, or
only the simplest CHECKMULTISIG case?
On Thursday, February 12, 2015 9:42:23 PM Thomas Kerin wrote:
> Hi all,
>
> I have drafted a BIP with Jean Pierre and Ruben after the last
> discussion, related to a standard for de
On Saturday, February 14, 2015 2:23:47 PM Tamas Blummer wrote:
> We have seen that the consensus critical code practically extends to
> Berkley DB limits or OpenSSL laxness, therefore it is inconceivable that a
> consensus library is not the same as Bitcoin Core, less its P2P service
> rules, walle
On Monday, May 11, 2015 7:03:29 AM Sergio Lerner wrote:
> 1. It will encourage centralization, because participants of mining
> pools will loose more money because of excessive initial block template
> latency, which leads to higher stale shares
>
> When a new block is solved, that information nee
It should actually be straightforward to softfork RCLTV in as a negative CLTV.
All nLockTime are >= any negative number, so a negative number makes CLTV a
no-op always. Therefore, it is clean to define negative numbers as relative
later. It's also somewhat obvious to developers, since negative nu
I think this hardfork is dead-on-arrival given the ideas for OP_CHECKSIG
softforking. Instead of referring to previous transactions by a normalised
hash, it makes better sense to simply change the outpoints in the signed data
and allow nodes to hotfix dependent transactions when/if they are mall
On Friday, May 15, 2015 9:54:55 AM s7r wrote:
> If you strip both the scriptSig of the parent and the txid, nothing can
> any longer be mutated but this is not safe against replays. This could
> work if we were using only one scriptPubKey per tx. But this is not
> enforced, ...
Assuming you mean o
On Tuesday, May 26, 2015 4:46:22 AM Kevin Greene wrote:
> This is something you actually don't want. In order to make it as difficult
> as possible for an attacker to perform a sybil attack, you want to choose a
> set of peers that is as diverse, and unpredictable as possible.
It doesn't hurt to h
On Wednesday, May 27, 2015 1:48:05 AM Pieter Wuille wrote:
> Feel free to comment. As the gist does not support notifying participants
> of new comments, I would suggest using the mailing list instead.
I suggest adding a section describing how this interacts with and changes GBT.
Currently, the c
On Saturday, June 06, 2015 2:35:17 PM Kalle Rosenbaum wrote:
> Current methods of proving a payment:
>
> * Signing messages, chosen by the server, with the private keys used to
> sign the transaction. This could meet 1 and 2 but probably not 3. This is
> not standardized either. 4 Could be met if
On Saturday, June 06, 2015 9:25:02 PM Kalle Rosenbaum wrote:
> * The pop output will have value 0.
Why not have it be -1 to make it completely invalid as a transaction?
Luke
--
___
On Friday, June 12, 2015 11:01:02 PM Vincent Truong wrote:
> RE: miner economics
> Miners who have an agenda can forego fees to achieve it and create their
> own txns if it is completely txn/user driven. It is better to just count
> miners votes and let the user votes be their backing.
Just simpli
On Tuesday, June 16, 2015 3:30:44 AM Kevin Greene wrote:
> Would SPV wallets have to pay to connect to the network too? From the
> user's perspective, it would be somewhat upsetting (and confusing) to see
> your balance slowly draining every time you open your wallet app. It would
> also tie up out
On Saturday, June 20, 2015 1:23:03 AM Aaron Voisine wrote:
> They don't need to be made cryptographically safe, they just have to be
> safer than, for instance, credit card payments that can be charged back. As
> long as it's reasonably good in practice, that's fine.
They never will be. You can ge
On Wednesday, April 30, 2014 6:03:59 PM Tier Nolan wrote:
> Due to "popular" demand, I have created a BIP for cross chain atomic
> transfers.
>
> https://github.com/TierNolan/bips/blob/bip4x/bip-atom.mediawiki
Instead of TX0, TX1, etc, can you put some kind of meaningful identifier for
these tra
On Saturday, May 03, 2014 12:54:37 AM Ben Davenport wrote:
> My only addition is that I think we should all stop trying to attach SI
> prefixes to the currency unit. Name me another world currency that uses SI
> prefixes. No one quotes amounts as 63 k$ or 3 M$. The accepted standard at
> least in t
40 matches
Mail list logo
