On 05/25/2015 10:03 PM, Matt Whitlock wrote:
On Monday, 25 May 2015, at 8:41 pm, Mike Hearn wrote:
some wallets (e.g., Andreas Schildbach's wallet) don't even allow it - you
can only spend confirmed UTXOs. I can't tell you how aggravating it is to
have to tell a friend, Oh, oops, I can't pay
Hi Andrew,
Your belief that Bitcoin has to be constrained by the belief that hardware
will never improve is extremist, but regardless, your concerns are easy to
assuage: there is no requirement that the block chain be stored on hard
disks. As you note yourself the block chain is used for
Hi Thomas,
My problem is that this seems to lacks a vision.
Are you aware of my proposal for network assurance contracts?
There is a discussion here:
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07552.html
But I agree with Gavin that attempting to plan for 20
some wallets (e.g., Andreas Schildbach's wallet) don't even allow it - you
can only spend confirmed UTXOs. I can't tell you how aggravating it is to
have to tell a friend, Oh, oops, I can't pay you yet. I have to wait for
the last transaction I did to confirm first. All the more aggravating
Hello all,
With all the discussion about the Block size limit, I thought it would be
interesting to measure, in some sense, the average Tx size. Then given a fixed
average block period (Bp) of 10 minutes (i.e 600 seconds), all one needs to do
to estimate an average block size is ask the
If capacity grows, fewer individuals would be able to run full nodes.
Hardly. Nobody is currently exhausting the CPU capacity of even a normal
computer currently and even if we did a 20x increase in load overnight,
that still wouldn't even warm up most machines good enough to be always on.
Wallets are incentivised to do a better job with defragmentation already,
as if you have lots of tiny UTXOs then your fees end up being huge when
trying to make a payment.
The reason they largely don't is just one of manpower. Nobody is working on
it.
As a wallet developer myself, one way I'd
On Monday, 25 May 2015, at 8:41 pm, Mike Hearn wrote:
some wallets (e.g., Andreas Schildbach's wallet) don't even allow it - you
can only spend confirmed UTXOs. I can't tell you how aggravating it is to
have to tell a friend, Oh, oops, I can't pay you yet. I have to wait for
the last
On Mon, May 25, 2015 at 10:29:26PM +0200, Andreas Schildbach wrote:
I see this behavior all the time. I am using the latest release, as far as
I know. Version 4.30.
The same behavior occurs in the Testnet3 variant of the app. Go in there
with an empty wallet and receive one payment
Very nice Emin! This could be very useful as a building block for oracle
based services. If only there were opcodes for working with X.509 ;)
I'd suggest at least documenting in the FAQ how to extract the data from
the certificate:
openssl pkcs12 -in virtual-notary-cert-stocks-16070.p12 -nodes
On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:
CPFP also solves it just fine.
CPFP is a significantly more expensive way of paying fees than RBF,
particularly for the use-case of defragmenting outputs, with cost
savings ranging from 30% to 90%
Case 1: CPFP vs. RBF for increasing
On Mon, May 25, 2015 at 1:36 PM, Mike Hearn m...@plan99.net wrote:
This meme about datacenter-sized nodes has to die. The Bitcoin wiki is down
right now, but I showed years ago that you could keep up with VISA on a
single well specced server with today's technology. Only people living in a
CPFP also solves it just fine.
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give
On Mon, May 25, 2015 at 08:44:18PM +0200, Mike Hearn wrote:
Wallets are incentivised to do a better job with defragmentation already,
as if you have lots of tiny UTXOs then your fees end up being huge when
trying to make a payment.
The reason they largely don't is just one of manpower.
Nah don't make blocks 20mb, then you are slowing down block propagation and
blowing out conf tikes as a result. Just decrease the time it takes to make a
1mb block, then you still see the same propagation times today and just
increase the transaction throughput.
But don't you see the same trade-off in the end there? You're still
propagating the same amount of data over the same amount of time, so unless
I misunderstand, the costs of such a move should be approximately the same,
just in different areas. The risks as I understand are as follows:
20MB:
Frankly I'm good with either way. I'm definitely in favor of faster
confirmation times.
The important thing is that we need to increase the amount of transactions
that get into blocks over a given time frame to a point that is in line
with what current technology can handle. We can handle WAY
I wouldn't say same trade-off because you need the whole 20mb block before you
can start to use it where as a 1mb block can be used quicker thus transactions
found in tge block quicker etc. As for tge higher rate of orphans, I think this
would be complimented by a faster correction rate, so if
Indeed Jim, your internet connection makes a good reason why I don't like 20mb
blocks (right now). It would take you well over a minute to download the block
before you could even relay it on, so much slow down in propagation! Yes I do
see how decreasing the time to create blocks is a bit of a
On Tuesday, 26 May 2015, at 1:15 am, Peter Todd wrote:
On Tue, May 26, 2015 at 12:52:07AM -0400, Matt Whitlock wrote:
On Monday, 25 May 2015, at 11:48 pm, Jim Phillips wrote:
Do any wallets actually do this yet?
Not that I know of, but they do seed their address database via DNS, which
Who would be performing a Sybil attack against themselves? We're talking about
a LAN here. All the nodes would be under the control of the same entity. In
that case, you actually want them all connecting solely to a central hub node
on the LAN, and the hub node should connect to diverse and
I don't see how the fact that my 2Mbps connection causes me to not be a
very good relay has any bearing on whether or not the network as a whole
would be negatively impacted by a 20MB block. My inability to rapidly
propagate blocks doesn't really harm the network. It's only if MOST relays
are as
Incidentally, even once we have the Internet of Things brought on by 21,
Inc. or whoever beats them to it, I would expect the average home to have
only a single full node hub receiving the blockchain and broadcasting
transactions created by all the minor SPV connected devices running within
the
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.
On Mon, May 25, 2015 at 9:37 PM, Matt Whitlock b...@mattwhitlock.name
wrote:
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
Sync time wouldn't be longer compared to 20MB, it would (eventually) be
longer under either setup.
Also, and this is probably a silly concern, but wouldn't changing block
time change the supply curve? If we cut the rate in half or a power of two,
that affects nothing, but if we want to keep it in
This is very simple to do. Just ping the all nodes address (ff02::1) and try
connecting to TCP port 8333 of each node that responds. Shouldn't take but more
than a few milliseconds on any but the most densely populated LANs.
On Monday, 25 May 2015, at 11:06 pm, Jim Phillips wrote:
Is there
Do any wallets actually do this yet?
On May 25, 2015 11:37 PM, Matt Whitlock b...@mattwhitlock.name wrote:
This is very simple to do. Just ping the all nodes address (ff02::1) and
try connecting to TCP port 8333 of each node that responds. Shouldn't take
but more than a few milliseconds on any
Summary
---
First-seen-safe replace-by-fee (FSS RBF) does the following:
1) Give users effective ways of getting stuck transactions unstuck.
2) Use blockchain space efficiently.
without:
3) Changing the status quo with regard to zeroconf.
The current Bitcoin Core implementation has
This is true, but the device doesn't know if the LAN it's on is a safe
network or a hotel wifi, for example. So there would be a tricky UX there.
You'd have to ask the user during set up if this is a trusted LAN or not;
or something like that. That may not be an issue though depending on the
On Tue, May 26, 2015 at 12:52:07AM -0400, Matt Whitlock wrote:
On Monday, 25 May 2015, at 11:48 pm, Jim Phillips wrote:
Do any wallets actually do this yet?
Not that I know of, but they do seed their address database via DNS, which
you can poison if you control the LAN's DNS resolver. I
Is there any work being done on using some kind of zero-conf service
discovery protocol so that lightweight clients can find a full node on the
same LAN to peer with rather than having to tie up WAN bandwidth?
I envision a future where lightweight devices within a home use SPV over
WiFi to
On Monday, 25 May 2015, at 11:48 pm, Jim Phillips wrote:
Do any wallets actually do this yet?
Not that I know of, but they do seed their address database via DNS, which you
can poison if you control the LAN's DNS resolver. I did this for a Bitcoin-only
Wi-Fi network I operated at a remote
33 matches
Mail list logo
