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 get
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
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 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
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
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 one
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
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
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 needs
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, wallet
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
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 dynamically
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 are
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
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
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 vs
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
- BIP 21
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 hint that
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 actual
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 time
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 l...@dashjr.org 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 GET-TXIN-BLOCK-(TIME
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 independently
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 soon as
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.
My
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 the miner
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 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 append
On Tuesday, July 15, 2014 3:11:25 PM Jeff Garzik wrote:
On Tue, Jul 15, 2014 at 10:48 AM, Luke Dashjr l...@dashjr.org 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 once. There might
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
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 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 the
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
35 matches
Mail list logo
