On Wed, Jun 17, 2015 at 1:00 AM, Mark Friedenbach m...@friedenbach.org wrote:
Given that we have had more than two weeks of public discussion, code is
available and reviewed, and several community identified issues resolved, I
would like to formally request a BIP number be assigned for this
On Sat, Jun 6, 2015 at 4:42 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Title: Canonical Input and Output Ordering
Author: Rusty Russell ru...@rustcorp.com.au
Discussions-To: Bitcoin Dev bitcoin-development@lists.sourceforge.net
Status: Draft
Type: Standards Track
Created: 2015-06-06
On Mon, Jun 8, 2015 at 9:25 PM, Danny Thorpe danny.tho...@gmail.com wrote:
Recommending sorting of the inputs and outputs as a best practice is fine
(and better than random, IMO), but not as part of IsStandard() or consensus
rules. There are cases where the order of the inputs and outputs is
On Sun, Jun 14, 2015 at 10:12 AM, Warren Togami Jr. wtog...@gmail.com wrote:
From the perspective of our community, for bitcoin-dev it seems like a great
fit. Why? While they are interested in supporting general open source
development, the LF has literally zero stake in this. In addition to
On Wed, May 27, 2015 at 7:47 AM, Peter Todd p...@petertodd.org wrote:
Equally this proposal is no more consensus enforcement than simply
increasing the fee (and possibly decreasing the absolute nLockTime) for
You've misunderstood it, I think-- Functionally nlocktime but relative
to each txin's
On Wed, May 27, 2015 at 9:59 PM, Mike Hearn m...@plan99.net wrote:
I wrote an article that explains the hashing assurance contract concept:
https://medium.com/@octskyward/hashing-7d04a887acc8
(it doesn't contain an in depth protocol description)
The prior (and seemingly this) assurance
On Tue, May 26, 2015 at 5:54 PM, Tom Harding t...@thinlink.com wrote:
It's not difficult to
imagine real-world consequences to not having contributed to the
transaction.
I'm having a hard time. Can you help me understand a specific case
where this makes a difference.
It appears to be a
On Tue, May 26, 2015 at 11:00 PM, Tom Harding t...@thinlink.com wrote:
The bitcoin transaction is part of a real-world deal with unknown
connections to the other parts
I'm having a hard time parsing this. You might as well say that its
part of a weeblix for how informative it is, since you've
It's a little frustrating to see this just repeated without even
paying attention to the desirable characteristics from the prior
discussions.
Summarizing from memory:
(0) Block coverage should have locality; historical blocks are
(almost) always needed in contiguous ranges. Having random
On Tue, May 12, 2015 at 8:10 PM, Jeff Garzik jgar...@bitpay.com wrote:
True. Part of the issue rests on the block sync horizon/cliff. There is a
value X which is the average number of blocks the 90th percentile of nodes
need in order to sync. It is sufficient for the [semi-]pruned nodes to
On Sun, May 10, 2015 at 9:21 PM, Gavin Andresen gavinandre...@gmail.com wrote:
a while I think any algorithm that ties difficulty to block size is just a
complicated way of dictating minimum fees.
Thats not the long term effect or the motivation-- what you're seeing
is that the subsidy gets in
On Sun, May 10, 2015 at 8:45 PM, Sergio Lerner
sergioler...@certimix.com wrote:
Can the system by gamed?
Users can pay fees or a portion of fees out of band to miner(s); this
is undetectable to the network.
It's also behavior that miners have engaged in since at least 2011 (in
two forms;
On Fri, May 8, 2015 at 8:33 PM, Mark Friedenbach m...@friedenbach.org wrote:
These rules create an incentive environment where raising the block size has
a real cost associated with it: a more difficult hashcash target for the
same subsidy reward. For rational miners that cost must be
On Sat, May 9, 2015 at 12:00 AM, Damian Gomez dgomez1...@gmail.com wrote:
...of the following:
the DH_GENERATION would in effect calculate the reponses for a total
overage of the public component, by addding a ternary option in the actual
DH key (which I have attached to sse if you can
On Wed, May 6, 2015 at 10:12 PM, Matt Corallo bitcoin-l...@bluematt.me
wrote: Recently there has been a flurry of posts by Gavin at
http://gavinandresen.svbtle.com/ which advocate strongly for increasing
the maximum block size. However, there hasnt been any discussion on this
mailing list in
On Fri, Apr 24, 2015 at 8:00 PM, Justus Ranvier
justus.ranv...@monetas.net wrote:
https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki
This link contains an RFC for a new type of Bitcoin address called a
payment code
Payment codes are SPV-friendly alternatives to
On Fri, Apr 24, 2015 at 7:58 PM, William Swanson swanson...@gmail.com wrote:
On Thu, Apr 16, 2015 at 9:12 AM, s7r s...@sky-ip.org wrote:
Thanks for your reply. I agree. Allen has a good point in the previous
email too, so the suggestion might not fix anything and complicate things.
The BIP 62
On Wed, Apr 8, 2015 at 7:50 PM, Stephen Morse
stephencalebmo...@gmail.com wrote:
Seeking feedback on a proposal that will allow a transaction signer to
explicitly specify what is to be serialized for the signature hash. The
basic idea is to make the nHashType general enough that we won't need a
On Tue, Apr 7, 2015 at 9:32 PM, Jean-Paul Kogelman
jeanpaulkogel...@me.com wrote:
https://eprint.iacr.org/2015/310.pdf
http://www.reddit.com/r/Bitcoin/comments/31rcuo/new_algorithm_for_the_discrete_logarithm_problem/cq4b52u
On Fri, Mar 27, 2015 at 1:51 AM, Thy Shizzle thyshiz...@outlook.com wrote:
Yes I agree, also there is talks about a government body I know of warming
to bitcoin by issuing addresses for use by a business and then all
transactions can be tracked for that business entity. This is one proposal I
On Thu, Mar 26, 2015 at 8:38 PM, Tom Harding t...@thinlink.com wrote:
I addressed that by limiting the duplicate check to an X-block segment. X
is hard-coded in this simple scheme (X=144 = 1-day addresses). You
could picture a selectable expiration duration too.
If its to be heuristic in
On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding t...@thinlink.com wrote:
I should have been clearer that the motivation for address expiration is to
reduce the rate of increase of the massive pile of bitcoin addresses out
there which have to be monitored forever for future payments. It could make
On Thu, Mar 26, 2015 at 10:28 PM, s7r s...@sky-ip.org wrote:
This should not be enforced by default.
No one suggested _anything_ like that. Please save the concern for
someplace its actually applicable.
I know it's not recommended to use the same pubkey more than once, but
the protocol was
This seems overly complicated to me, unless I'm missing something.
Instead, I think you should just give the server the master pubkey P
only without the chaincode.
Then when you transact you generate the address in whatever manner you
like and tell the server the scalar value iL which the user
On Wed, Mar 11, 2015 at 11:45 AM, Thomas Kerin m...@thomaskerin.io wrote:
I used BIP0090 as a place-holder, but I would like to request a BIP number
for this now.
We have had repeated problems in the past with people working on and
circulating prior draft proposals squatting on each others
On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
ricardojdfil...@gmail.com wrote:
i guess you look at the glass half full :)
even though what you say is true, we should aim for wallets not to
require those instructions, by standardizing these things in BIPs.
let's hope bitcoin doesn't fail in
On Wed, Mar 11, 2015 at 11:24 PM, Pindar Wong pindar.w...@gmail.com wrote:
Perhaps at some point consider introducing something akin to a
'Bitcoin-Draft' (BD) status with some autoexpiry period?
I understand that the Internet Engineering Task Force (IETF) has the
concept of 'Internet Drafts
On Wed, Mar 11, 2015 at 11:50 PM, devrandom c1.sf-bitc...@niftybox.net wrote:
That said, I do agree that mnemonic phrases should be portable, and find
it unfortunate that the ecosystem is failing to standardize on phrase
handling.
The fact remains that there are several apparently unresolvable
On Thu, Mar 12, 2015 at 2:41 AM, devrandom c1.sf-bitc...@niftybox.net wrote:
I think there are some important advantages to not being forced to use
the old wallet to send coins when switching wallets. The three I can
think of right now are: maintaining transaction history,
Just loading a key
It would appear that the Bitcoin Foundation has decided that their
next two seats would be decided by miners. (More information
available at:
https://bitcoinfoundation.org/forum/index.php?/topic/1255-blockchain-voting/#entry13453
)
Unfortunately, they seem to have not provided the software
On Fri, Feb 20, 2015 at 4:54 PM, Mike Hearn m...@plan99.net wrote:
And then what? So you know the block matches. But with reasonable FP rates
every block will match at least a few transactions (this is already the case
This approach needs a filter set with a lower FP rate. It doesn't
depend on
On Fri, Feb 20, 2015 at 5:59 PM, Adam Back a...@cypherspace.org wrote:
So now they ask a full node for merkle paths + transactions for the
addresses from the UTXO set from the block(s) that it was found in.
Use of the words UTXO set here is probably confusing people as it's
likely to make
On Thu, Feb 12, 2015 at 1:18 PM, Mike Hearn m...@plan99.net wrote:
history. Lots of miners have dropped out due to hardware obsolescence, yet
massive double spending hasn't happened.
How many thousands of BTC must be stolen by miners before you'd agree
that it has, in fact, happened?
On Wed, Feb 4, 2015 at 2:23 PM, Isidor Zeuner
cryptocurrenc...@quidecco.de 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 calculated miner fees, this
may
On Tue, Feb 3, 2015 at 12:44 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
The much simpler alternative is just adding this to BIP66's DERSIG
right now, which is a one-line change that's obviously softforking. Is
anyone opposed to doing so at this stage?
Thats my preference.
On Sun, Feb 1, 2015 at 8:08 PM, xor x...@freenetproject.org wrote:
Why is that?
Because Binaries on Bitcoin.org have always been unaffected by the
issue 0.9.4 was released to address.
Also, is it correct that there wasn't a release candidate before the release?
Sounds dangerous to me.
The
On Mon, Jan 26, 2015 at 5:14 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
On Tue, Jan 20, 2015 at 8:35 PM, Pieter Wuille pieter.wui...@gmail.com
wrote:
I therefore propose a softfork to make non-DER signatures illegal
(they've been non-standard since v0.8.0). A draft BIP text can be
On Fri, Jan 23, 2015 at 4:18 PM, slush sl...@centrum.cz wrote:
Can you send me any reference about this? Of course if that solves the
problem, hard fork would not be necessary anymore. I'm just not aware of
any.
Sure; will aggregate up the citations when I'm not travling later today.
To sign
On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner etothe...@gmail.com wrote:
Unfortunately, it seems that there was no soft-fork way to achieve this
benefit, at least not one that had favorable properties. Most of the
soft-fork variations of it required the coins being spent to have been
OpenSSL 1.0.0p / 1.0.1k was recently released and is being
pushed out by various operating system maintainers. My review
determined that this update is incompatible with the Bitcoin
system and could lead to consensus forks.
Bitcoin Core released binaries from Bitcoin.org are unaffected,
as are
On Fri, Jan 9, 2015 at 1:20 PM, Mike Hearn m...@plan99.net wrote:
A limitation on most existing micropayment channel ideas is that payments
can only flow in one direction.
It's worth noting that the original protocol as designed by Satoshi did not
have this limitation. It has evolved this way
On Fri, Jan 9, 2015 at 1:42 PM, Mike Hearn m...@plan99.net wrote:
Additionally, there is a school of thought that says Bitcoin must work even
if lots of miners are malicious and willing to break arbitrary things in
order to try and get more money. I don't think Bitcoin can really be a
This
On Sun, Jan 4, 2015 at 2:43 PM, Ross Nicoll j...@jrn.me.uk wrote:
Dear all,
I've been looking at atomic cross-chain trading (
https://en.bitcoin.it/wiki/Atomic_cross-chain_trading ) between the
Bitcoin and Dogecoin blockchains, and have a mostly functional
prototype. However as it stands if
On Sun, Jan 4, 2015 at 5:22 PM, Ross Nicoll j...@jrn.me.uk wrote:
Grabbing a simple test case:
https://chain.so/tx/BTCTEST/f903a31f2474df737d324c60abf2407e1cf7e052844da4ccffbfab81cf6ac1f8
- that won't lock until 0028 UTC on the 5th.
I've tried closing the wallet, moving the wallet.dat file
On Sun, Jan 4, 2015 at 5:35 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
Can you send me the actual raw transaction (that site doesn't appear
have a way to get it, only some cooked json output; which doesn't
include the sequence number).
Nevermind, I guess. I think I figured out your problem
On Tue, Dec 30, 2014 at 4:25 PM, Sergio Lerner
sergioler...@certimix.com wrote:
Slight off-topic:
That looks like an abuse of the VM. Even P2SH is an abuse of the VM.
Gavin's OP_EVAL (hard-fork) should had been chosen. I'm taking about a
simple change that goes along the lines of Satoshi's
On Mon, Dec 29, 2014 at 7:21 PM, Sergio Lerner
sergioler...@certimix.com 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
On Sat, Dec 20, 2014 at 11:14 AM, Jeremy Spilman jer...@taplink.co wrote:
are dnsseeds being blocked
ostensibly because they are acting as dyanamic DNS infrastructure for
malware sites?
Pretty much appears to be the case. In every instance it appears to be
automated. This predates the msft
On Mon, Dec 15, 2014 at 12:47 PM, Peter Todd p...@petertodd.org wrote:
[snip]
Pull-req #4890², specifically commit c7829ea7, changed the
This change was authored more than three months ago and merged more
than two months ago.
[And also, AFAICT, prior to you authoring BIP65]
I didn't participate
On Fri, Nov 28, 2014 at 11:45 AM, Flavien Charlon
flavien.char...@coinprism.com wrote:
This breaks existing invariants and would make the coins potentially less
fungible because they wouldn't be reorg safe.
I'm not sure coins are ever reorg safe. All it takes is a double spend in
the history
On Thu, Nov 27, 2014 at 10:56 PM, Richard Moore m...@ricmoo.com wrote:
Heya,
I was wondering about BIP 65 regarding the OP_CHECKLOCKTIMEVERIFY, and
thought it might make more sense to instead have a OP_CHECKLOCKTIME which
would simply push an OP_TRUE or OP_FALSE onto the stack?
Updating the
On Fri, Nov 28, 2014 at 12:45 AM, Mistr Bigs mister...@gmail.com wrote:
That's what I was trying to say... The researchers are deanonymizing
transactions from non-Tor connected hosts. So why are we talking about Tor
limitations in response to this? Shouldn't we be discussing how to address
the
Since this attack vector has been discussed, I started making some
measurements on how effective it is to connect to Bitcoin using Tor,
and I found that the number of connections dropping to near-zero is
a situation which occurs rather frequently, which suggests that there
is still room to
Some initial comments...
Tying in the protocol changes is really confusing and the fact that
they seem to be required out the gates would seemingly make this much
harder to deploy. Is there a need to do that? Why can't the p2p part
be entirely separate from the comitted data?
On Mon, Nov 10,
On Thu, Nov 6, 2014 at 11:12 PM, Peter Todd p...@petertodd.org wrote:
BIP62 does make life easier for wallet authors as they don't have to
deal with malleability - maybe! -
Yes, I agree for most contract purposes CTLV is what you want to be
using, instead of refund transactions beyond being
On Thu, Oct 30, 2014 at 11:18 PM, Rusty Russell ru...@rustcorp.com.au wrote:
Hi all,
I've been toying with an algorithm to place a ceiling on
confirmation latency by allowing weaker blocks after a certain time.
Hope this isn't noise, but thought someone must have considered this
On Tue, Oct 28, 2014 at 8:17 PM, Ferdinando M. Ametrano
ferdinando.ametr...@gmail.com wrote:
On Oct 25, 2014 9:19 PM, Gavin Andresen gavinandre...@gmail.com wrote:
We had a halving, and it was a non-event.
Is there some reason to believe next time will be different?
In november 2008
On Tue, Oct 28, 2014 at 9:19 PM, Jérémie Dubois-Lacoste
jeremie...@gmail.com wrote:
The fact that a topic was brought up many times since a long time,
does not mean it is not relevant.
I am not saying that it is not relevant, I'm saying the discussion
is pointless:
No new information has
On Tue, Oct 28, 2014 at 2:26 AM, Tom Harding t...@thinlink.com wrote:
Matt,
You're right, thanks. Without double-spend relay, miner won't know that
some txes conflict with anything.
Even with that, the miner cannot tell, his only safe option is to
include no transactions at all.
Consider a
On Wed, Oct 15, 2014 at 8:29 AM, Wladimir laa...@gmail.com wrote:
Hello,
I'm trying to create a bit of process around the
https://github.com/bitcoin/bips repository.
A) Currently a lot of pulls are open for various BIPs and it is not
clear who should comment on them, or who decides on
On Tue, Oct 14, 2014 at 7:27 AM, Thomas Zander tho...@thomaszander.se wrote:
What about rejecting a script where a bool is not explicitly zero or one?
I believe this is what he actually meant.
--
Comprehensive Server
On Tue, Oct 14, 2014 at 2:34 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
Hi all,
while working on a BIP62 implementation I discovered yet another type
of malleability: the interpretation of booleans.
Any byte array with non-zero bytes in it (ignoring the highest bit of
the last byte,
On Sat, Oct 11, 2014 at 11:34 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
* Parallel block downloading (much faster sync on typical network
connections).
Much faster is an understatement. Benchmarking here shows one hour
five minutes syncing to 295000. Old code isn't even at 25
On Thu, Oct 9, 2014 at 6:14 AM, Adam Back a...@cypherspace.org wrote:
I think you can do everything with the existing script level nlocktime
in some kind of turing completeness sense (maybe); but there is a
complexity cost that often you have to resort to extra dependent
transaction(s) (and
On Thu, Oct 9, 2014 at 6:33 AM, Peter Todd p...@petertodd.org wrote:
Speaking of, can anyone think of an example of a complex transaction
use-case that is affected by malleability which can't be fixed by
CHECKLOCKTIMEVERIFY? I'm sure they exist, but I'm scratching my head
trying to think of a
On Tue, Oct 7, 2014 at 7:04 PM, Sergio Lerner sergioler...@certimix.com wrote:
Using the my previous terminology, automatic fee-sharing (ORBS) is a
solution to the freeze problem (FRONT) but opens the windows to
CHAKIDO double-spending. and CHAKIDO double-spending is a much worse
problem than
On Sun, Oct 5, 2014 at 4:00 PM, Sergio Lerner sergioler...@certimix.com wrote:
I would like to share with you a vulnerability in the Bitcoin protocol I've
been thinking of which might have impact on the future of Bitcoin. Please
criticize it!
The Freeze on Transaction Problem
I should point
On Sun, Oct 5, 2014 at 4:40 PM, Gregory Maxwell gmaxw...@gmail.com
I should point you to some of the tools that have been discussed in
the past which are potentially helpful here:
Ah, I should also mention a somewhat more far out approach which helps
here as a side effect:
If transactions were
On Sun, Oct 5, 2014 at 4:54 PM, Jorge Timón jti...@blockstream.io wrote:
In any case, it is interesting to think about this things since mining
subsidies will eventually disappear and then transaction fees will
ALWAYS be higher than subsidies.
You can imagine that instead of subsidy Bitcoin
On Fri, Oct 3, 2014 at 7:28 AM, Matt Whitlock b...@mattwhitlock.name 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?
This would not be soft-forking compatible.
It also would be unsafe in that it
On Tue, Aug 19, 2014 at 10:11 AM, Justus Ranvier jus...@monetas.net wrote:
Two draft information BIPs are attached.
I've pinged some people privately but also pinging the list… no
commentary on this proposal?
--
Meet
On Mon, Sep 15, 2014 at 3:51 PM, Matt Whitlock b...@mattwhitlock.name wrote:
On Monday, 15 September 2014, at 5:10 pm, Thomas Zander wrote:
So for instance I start including a bitcoin public key in my email signature.
I don't sign the emails or anything like that, just to establish that
On Fri, Jul 18, 2014 at 8:14 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
Hi all,
I've sent a pull request to make a small change to BIP 62 (my
anti-malleability proposal) which is still a draft; see:
* https://github.com/bitcoin/bips/pull/90 (the request)
*
On Sat, Aug 23, 2014 at 1:36 PM, Paul Rabahy prab...@gmail.com wrote:
I want go give a bit of an outsiders perspective. I thoroughly understand
the concepts of bitcoin and am a professional programmer, but have never
taken the time to compile my own copy of bitcoin core.
I have looked at the
On Tue, Aug 19, 2014 at 9:07 AM, Justus Ranvier
justusranv...@riseup.net wrote:
If that's not acceptable, even using TLS with self-signed certificates
would be an improvement.
TLS is a huge complex attack surface, any use of it requires an
additional dependency with a large amount of difficult
On Tue, Aug 19, 2014 at 5:02 AM, Jeff Garzik jgar...@bitpay.com wrote:
It would be nice if the issues and git repo for Bitcoin Core were not
on such a centralized service as github, nice and convenient as it is.
To that end, I note that Linux does its own git repo, and now requires
2FA:
On Tue, Aug 19, 2014 at 4:39 PM, Justus Ranvier
justusranv...@riseup.net wrote:
While the rest of the 'net is busy deprecating HTTP and all other
unencrypted transport methods, why is it(*) even a debate?
I think it's desirable (and you can go look in #bitcoin-dev logs for
me talking about it
On Tue, Aug 19, 2014 at 6:26 PM, Troy Benjegerdes ho...@hozed.org wrote:
If a project cannot be organized enough to run its own hosting/web presense/
counterintelligence/security that starts with installing an OS and patching
kernels, then it is really not wise for me to trust my financial
On Mon, Aug 18, 2014 at 9:46 AM, Ivan Pustogarov ivan.pustoga...@uni.lu wrote:
Hi there,
I'd like to start a discussion on periodic rotation of outbound connections.
E.g. every 2-10 minutes an outbound connections is dropped and replaced
by a new one.
Connection rotation would be fine for
On Mon, Aug 18, 2014 at 10:30 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
Yes, I believe peer rotation is useful, but not for privacy - just for
improving the network's internal knowledge.
I haven't looked at the implementation yet, but how I imagined it would be
every X minutes you
On Mon, Aug 18, 2014 at 11:37 AM, Ivan Pustogarov
ivan.pustoga...@uni.lu wrote:
the same for a long time, an attacker which does not have any peers at all
but just listens the Bitcoin network can link together differed BC addresses
and learn the IP of the client.
I don't understand what you're
On Mon, Aug 18, 2014 at 1:33 PM, Ivan Pustogarov ivan.pustoga...@uni.lu wrote:
The attack I'm trying to address is described here:
https://www.cryptolux.org/index.php/Bitcoin
It was discussed here: https://bitcointalk.org/index.php?topic=632124.0
It uses the following observation. Each NATed
On Mon, Aug 18, 2014 at 2:02 PM, Ivan Pustogarov ivan.pustoga...@uni.lu wrote:
For each neighbour, a Bitcoin peer keeps the history of addresses that
it forwarded to the neighbour. If an address was already forwarded
to a neighbour it is not retransmitted again.
Okay, sorry, I thought you were
On Thu, Jul 31, 2014 at 1:47 PM, Kaz Wesley kezi...@gmail.com wrote:
trip to request the missing tx; if we could somehow get the What's
the Difference approach to effectively operate on full transactions
instead
I explain how to do this on the network block coding page.
Given that you know
On Thu, Jul 31, 2014 at 2:41 PM, Kaz Wesley kezi...@gmail.com wrote:
the need to have transmitted the transaction list [..] first
32 bits per transaction is at least double the communication overhead
of the simple approach, and only offers a bound on the probability of
needing a round trip.
On Thu, Jul 31, 2014 at 3:27 PM, Kaz Wesley kezi...@gmail.com wrote:
the FEC still lets you fill in the missing transactions without knowing in
advance all that will be missing.
I don't see why we need to solve that problem, since the protocol
already involves exchanging the information
On Thu, Jul 31, 2014 at 6:38 PM, Matt Whitlock b...@mattwhitlock.name wrote:
It would make more sense to introduce a new script opcode that pushes the
current block height onto the operand stack. Then you could implement
arbitrary logic about which blocks the transaction can be valid in. This
On Thu, Jul 31, 2014 at 8:26 PM, Matt Whitlock b...@mattwhitlock.name wrote:
I understand what you're saying, but I don't understand why it's a problem.
Transactions shouldn't be considered final until a reasonable number of
confirmations anyway, so the possibility that an accepted
On Mon, Jul 28, 2014 at 5:31 AM, Robert McKay rob...@mckay.com wrote:
I don't think Sybil attack is the right term for this.. there is only
one IP address.. one identity.
The bitcoin protocol is more or less identityless. It's using up lots
of network capacity, number of sockets is as pretty
On Sun, Jul 27, 2014 at 7:12 PM, Jeremy jlru...@mit.edu 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 mostly plaintext Bitcoin traffic.
On Sun, Jul 27, 2014 at 7:40 PM, Peter Todd p...@petertodd.org wrote:
Anyway, just goes to show that we need to implement better incoming
connection limiting. gmaxwell has a good scheme with interactive
proof-of-memory - where's your latest writeup?
Or its a complete snipe hunt, I'm unable to
On Sun, Jul 27, 2014 at 7:45 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
Or its a complete snipe hunt, I'm unable to find any nodes with it
connected to them. Does anyone here have any?
[unimportant update] Turns out that my IPv4 nodes already have
iptables blocking of that subnet, presumably
On Sun, Jul 27, 2014 at 7:54 PM, m...@bitwatch.co m...@bitwatch.co wrote:
These website list Tor nodes by bandwidth:
http://torstatus.blutmagie.de/index.php
https://torstatus.rueckgr.at/index.php?SR=BandwidthSO=Desc
And the details reveal it's a port 8333 only exit node:
On Thu, Jul 24, 2014 at 7:35 PM, Aaron Voisine vois...@gmail.com wrote:
The upcoming release of breadwallet uses the height of the blockchain to
enforce timed pin code lockouts for preventing an attacker from quickly
making multiple pin guesses. This prevents them changing the devices system
On Mon, Jul 21, 2014 at 12:24 PM, Peter Todd p...@petertodd.org wrote:
Might be worthwhile to also write an Expectations for DNSSeed users
outlining what security properties the seeds actually have, and what
kind of attacks are possible.
Agreed. I've seen some amount of use of dnsseeds which
On Fri, Jul 18, 2014 at 8:06 PM, Emin Gün Sirer el33th4...@gmail.com wrote:
Most things I've seen working in this space are attempting to minimize
the data transfered. At least for the miner-interested case the round
complexity is much more important because a single RTT is enough to
On Fri, Jul 18, 2014 at 9:38 PM, Aaron Voisine vois...@gmail.com wrote:
Well, you could always create a transaction with a different signature
hash, say, by changing something trivial like nLockTime, or changing
the order of inputs or outputs. Is that what you're talking about? Or
is there
On Fri, Jul 18, 2014 at 9:33 PM, Richard Moore m...@ricmoo.com wrote:
Hey all,
I'm wondering if anyone can help explain to me tx
70f7c15c6f62139cc41afa858894650344eda9975b46656d893ee59df8914a3d...
A rather timely post. See the other thread on BIP0062. What you're
looking at is an example of
On Fri, Jul 18, 2014 at 5:54 PM, Emin Gün Sirer el33th4...@gmail.com wrote:
The problem being tackled here is very similar to set reconciliation,
where
peer A thinks that the set of transactions that should be in the block is
S_A,
Most things I've seen working in this space are attempting to
On Fri, Jul 18, 2014 at 3:03 PM, Aaron Voisine vois...@gmail.com wrote:
9. New signatures by the sender
I'm not suggesting it be required, but it would be possible to
mitigate this one by requiring that all signatures deterministically
generate k per RFC6979. I'm using this in breadwallet.
1 - 100 of 322 matches
Mail list logo
