Thanks for the feedback Mark.
> (1) there is absolutely no reason to include asset tagging information if
it is not validated
Sure, there is a good reason to include it in the blockchain: so that
clients don't need external information to recognize colored coins. Also,
I'm not sure what you mean
>
> Have you seen the padded order-based coloring scheme worked out here?
>
> https://github.com/bitcoinx/colored-coin-tools/wiki/colored_coins_intro
Just to clarify, a variant of padded order-based coloring called epobc is
already implemented in coloredcoinlib (which is used by
ngcccbase/ChromaW
At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and
still falling:
http://getaddr.bitnodes.io/dashboard/chart/?days=60
I know all the reasons why people *might* stop running a node (uses too
much disk space, bandwidth, lost interest etc). But does anyone have any
idea h
phasing out of bitcoinqt into spv wallets?
2014-04-07 12:34 GMT+01:00 Mike Hearn :
> At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and
> still falling:
>
>http://getaddr.bitnodes.io/dashboard/chart/?days=60
>
> I know all the reasons why people might stop running a no
I'm glad to see that I'm not the only one concerned about the consistent
dropping of nodes. Though I think that the fundamental question should be: how
many nodes do we really need? Obviously more is better, but it's difficult to
say how concerned we should be without more information. I posted
On 4/7/14, Flavien Charlon wrote:
> Also those 54 BTC (actually 5.4 BTC if the dust is now 540 satoshis) become
> part of the capital of the company, and can always be recovered by
> uncoloring the shares. It's an investment, not an expense, so I think it is
> acceptable.
This doesn't make much s
On Mon, Apr 7, 2014 at 2:19 PM, Jameson Lopp wrote:
> I'm glad to see that I'm not the only one concerned about the consistent
> dropping of nodes. Though I think that the fundamental question should be:
> how many nodes do we really need? Obviously more is better, but it's
> difficult to say h
>
> In my opinion, the number of full nodes doesn't matter (as long as
> it's enough to satisfy demand by other nodes).
>
Correct. Still, a high number of nodes has a few other benefits:
1) The more nodes there are, the cheaper it should be to run each one,
given that the bandwidth and CPU for se
On 04/07/2014 08:26 AM, Pieter Wuille wrote:
> In my opinion, the number of full nodes doesn't matter (as long as
> it's enough to satisfy demand by other nodes).
I agree, but if we don't quantify "demand" then we are practically blind. What
is the plan? To wait until SPV clients start lagging /
They're _not_ phasing out into SPV wallets from what I can say. At
around the 24th of February, there has been a sharp change of the
"current installs" graph of Bitcoin Wallet. That number used to grow at
about 20.000 per month. After that date until now, it just barely moves
horizontal.
My guess
On Mon, Apr 7, 2014 at 4:34 AM, Mike Hearn wrote:
> At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and
> still falling:
FWIW, A few months before that we had even less than 8500 by the bitnodes count.
Bitcoin.org recommends people away from running Bitcoin-QT now, so I'm
On Mon, Apr 7, 2014 at 6:50 AM, Gregory Maxwell wrote:
> FWIW, A few months before that we had even less than 8500 by the bitnodes
> count.
Gah, accidentally send I wanted to continue here that it was less
than 8500 and had been falling pretty consistently for months,
basically since the bit
The Bitnodes project updated their counting algorithm a month or so ago. It
used to be slower and less accurate - prior to their update, it was reporting
in excess of 100,000 nodes.
- Jameson
On 04/07/2014 09:53 AM, Gregory Maxwell wrote:
> On Mon, Apr 7, 2014 at 6:50 AM, Gregory Maxwell wrote
Jorge, they'd have to be. Otherwise, assuming the price of the share goes
low enough, you could buy a share of the company, melt the gold plate, and
sell it for a profit. If the gold is part of the capital of the company,
the cheapest a share can be is the price of the gold on which the stock
certi
On Mon, Apr 7, 2014 at 6:58 AM, Jameson Lopp wrote:
> The Bitnodes project updated their counting algorithm a month or so ago. It
> used to be slower and less accurate - prior to their update, it was reporting
> in excess of 100,000 nodes.
Nah. It reported multiple metrics. The "100,000" numbe
>
> My guess is that a large number of users have lost interest after they
> lost their money in MtGox. The 24th of February coincides with the
> "final" shutdown
Sigh. It would not be surprising if MtGox has indeed dealt the community a
critical blow in this regard. TX traffic is down since then
Indeed, fully agreed. The only way to really make progress here is to make
the UX of being your own bank not only as good as trusting a third party,
but better.
I've been encouraged by the rise of risk analysis services, but we need to
integrate them into wallets more widely for them to have much
We need to make it so mind-numbingly simple to "run Bitcoin correctly" that
the average user doesn't find reasons to do so in the course of normal
use. Right now, Coinbase and Bitstamp are winning in the user experience
battle, which technically endanger the user, and by proxy the Bitcoin
network.
Flavien, capital is wealth or resources available for the stated purpose
of the company. These bitcoins represent nothing more than a speculative
floor owned by the investors, not the company.
On 04/07/2014 07:00 AM, Flavien Charlon wrote:
> Jorge, they'd have to be. Otherwise, assuming the price
On 4/7/2014 7:05 AM, Mike Hearn wrote:
> Some days I wonder if Bitcoin will be killed off by people who just
> refuse to use it properly before it ever gets a chance to shine. The
> general public doesn't distinguish between "Bitcoin users" who deposit
> with a third party and the real Bitcoin u
Ok, I guess I'm not using the proper terminology. It would be listed on the
"Asset" section of the company's balance sheet, is what I meant.
On Mon, Apr 7, 2014 at 4:06 PM, Mark Friedenbach wrote:
> Flavien, capital is wealth or resources available for the stated purpose
> of the company. These
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/07/2014 11:34 AM, Mike Hearn wrote:
> At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and
> still falling:
>
>http://getaddr.bitnodes.io/dashboard/chart/?days=60
>
> I know all the reasons why people *might* stop run
On Mon, Apr 7, 2014 at 8:45 AM, Justus Ranvier wrote:
> 1. The resource requirements of a full node are moving beyond the
> capabilities of casual users. This isn't inherently a problem - after
> all most people don't grow their own food, tailor their own clothes, or
> keep blacksmith tools handy
I would point to bandwidth as the most important issue to the casual user who
runs a node at home. Few casual users have the know-how to set up QoS rules and
thus become quite annoyed when their Internet connection is discernibly slowed.
- Jameson
On 04/07/2014 11:53 AM, Gregory Maxwell wrote:
Right now running a full-node on my home DSL connection (<1Mbps) makes
other internet activity periodically unresponsive. I think we've already
hit a point where resource requirements are pushing out casual users,
although of course we can't be certain that accounts for all lost nodes.
On 04/07/20
On Mon, Apr 7, 2014 at 9:27 AM, Mark Friedenbach wrote:
> Right now running a full-node on my home DSL connection (<1Mbps) makes
> other internet activity periodically unresponsive. I think we've already
> hit a point where resource requirements are pushing out casual users,
> although of course w
For what it's worth, the number of nodes rose dramatically during the China
bullrun (I recall 45k in China alone) and dropped as dramatically as the
price after the first PBOC announcement designed to cool down bitcoin
trading in China.
On 7 April 2014 12:34, Mike Hearn wrote:
> At the start of
On Mon, Apr 7, 2014 at 10:01 AM, Mark Friedenbach wrote:
> On 04/07/2014 09:57 AM, Gregory Maxwell wrote:
>> That is an implementation issue— mostly one that arises as an indirect
>> consequence of not having headers first and the parallel fetch, not a
>> requirements issue.
>
> Oh, absolutely. Bu
On 04/07/2014 09:57 AM, Gregory Maxwell wrote:
> That is an implementation issue— mostly one that arises as an indirect
> consequence of not having headers first and the parallel fetch, not a
> requirements issue.
Oh, absolutely. But the question "why are people not running full
nodes?" has to do
How difficult would it be to set up a node? Using lots of electricity at
home (if required) could be an issue, but I do have a Webfaction account.
On Mon, Apr 7, 2014 at 12:16 PM, Gregory Maxwell wrote:
> On Mon, Apr 7, 2014 at 10:01 AM, Mark Friedenbach
> wrote:
> > On 04/07/2014 09:57 AM, Gr
It uses ~no electricity, it's not like mining.
The primary resources it needs are disk space and bandwidth, after an
intensive initial day or two of building the database.
Actually, I wonder if we should start shipping (auditable) pre-baked
databases calculated up to the last checkpoint so people
On Mon, Apr 7, 2014 at 10:40 AM, Mike Hearn wrote:
> Actually, I wonder
The actual validation isn't really the problem today. The slowness of
the IBD is almost exclusively the lack of parallel fetching and the
existence of slow peers. And making the signature gate adaptive (and
deploying the 6x
I rather prefer to start with SPV and upgrade to full node, if desired.
Tamas Blummer
http://bitsofproof.com
On 07.04.2014, at 19:40, Mike Hearn wrote:
>
> Actually, I wonder if we should start shipping (auditable) pre-baked
> databases calculated up to the last checkpoint so people can downl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/07/2014 05:16 PM, Gregory Maxwell wrote:
> When I read "resource requirements of a full node are moving
> beyond" I didn't extract from that that "there are implementation
> issues that need to be improved to make it work better for low
> resourc
Okay awesome. It seems like I set up a Litecoin node without knowing it
(because it was like this:
https://bitcointalk.org/index.php?topic=128122.0) I was able to bootstrap
it (https://litecoin.info/).
On Mon, Apr 7, 2014 at 12:40 PM, Mike Hearn wrote:
> It uses ~no electricity, it's not like m
I’m afraid this is a highly simplistic view of the costs of running a full node.
My node consumes fantastic amounts of data traffic, which is a real cost.
In the 30 days ending Apri 6, my node:
* Received 36.8 gb of data
* Sent 456.5 gb data
At my geographic service location (Singapore), this c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/07/2014 05:40 PM, Mike Hearn wrote:
> The primary resources it needs are disk space and bandwidth, after
> an intensive initial day or two of building the database.
Check out the kind of hardware causal users are running these days.
The bottlen
>
> * Sent 456.5 gb data
>
> At my geographic service location (Singapore), this cost about $90 last
> month for bandwidth alone.
One of the reasons I initiated the (now stalled) PayFile project was in
anticipation of this problem:
https://github.com/mikehearn/PayFile
http://www.youtube.com/watc
On 4/7/14, Flavien Charlon wrote:
> Ok, I guess I'm not using the proper terminology. It would be listed on the
> "Asset" section of the company's balance sheet, is what I meant.
No, it's an asset for the owner of the share, not the company, just
like the gold plates are not assets for the compan
Headers first loading allows the node to run SPV from the very first minutes
and it can converge to full node by time.
This is BTW how newest versions of BOP can work.
Pruning however disqualifies the node as a source for bootstrapping an other
full node.
BTW, did we already agree on the servic
On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer wrote:
> BTW, did we already agree on the service bits for an archive node?
I'm still very concerned that a binary archive bit will cause extreme
load hot-spotting and the kind of binary "Use lots of resources YES or
NO" I think we're currently suffe
Once a single transaction in pruned in a block, the block is no longer eligible
to be served to other nodes.
Which transactions are pruned can be rather custom e.g. even depending on the
wallet(s) of the node,
therefore I guess it is more handy to return some bitmap of pruned/full blocks
than r
On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer wrote:
> Once a single transaction in pruned in a block, the block is no longer
> eligible to be served to other nodes.
> Which transactions are pruned can be rather custom e.g. even depending on
> the wallet(s) of the node,
> therefore I guess it is
> The bottleneck is not bulk disk space, but rather IOPS.
Exactly. I stopped running a full node on both of my desktops machines
in the last month. Both systems were simply becoming very noticeable
(=unbearably) sluggish. I am also running dedicated nodes, which are
fine, but on a desktop latency
On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer wrote:
> therefore I guess it is more handy to return some bitmap of pruned/full
> blocks than ranges.
A bitmap also means high overhead and— if it's used to advertise
non-contiguous blocks— poor locality, since blocks are fetched
sequentially.
On 04/07/2014 12:00 PM, Tamas Blummer wrote:
> Once a single transaction in pruned in a block, the block is no longer
> eligible to be served to other nodes.
> Which transactions are pruned can be rather custom e.g. even depending
> on the wallet(s) of the node,
> therefore I guess it is more hand
Maybe it is not a question of the maturity of the implementation but that of
the person making presumptions of it.
I consider a fully pruned blockchain being equivalent to the UTXO. Block that
hold no
more unspent transaction are reduced to a header. There is however no harm if
more retained.
On Mon, Apr 7, 2014 at 8:03 PM, Gregory Maxwell wrote:
> A bitmap also means high overhead and-- if it's used to advertise
> non-contiguous blocks-- poor locality, since blocks are fetched
> sequentially.
>
A range seems like a great compromise. Putting it in the address is also a
pretty cool.
Once headers are loaded first there is no reason for sequential loading.
Validation has to be sequantial, but that step can be deferred until the blocks
before a point are loaded and continous.
Tamas Blummer
http://bitsofproof.com
On 07.04.2014, at 21:03, Gregory Maxwell wrote:
> On Mon, Ap
An IOU written in a gold plate sure makes no sense. I see what you are
saying, the inconvenience comes from the fact that the buyer has to buy
some amount of BTC at the same time as he buys a share.
That's why I was making the point that you could have a colored coin
representing a single share, a
On 04/07/2014 12:20 PM, Tamas Blummer wrote:
> Validation has to be sequantial, but that step can be deferred until the
> blocks before a point are loaded and continous.
And how do you find those blocks?
I have a suggestion: have nodes advertise which range of full blocks
they possess, then you
You have the trunk defined by the headers. Once a range from genesis to block n
is fully downloaded,
you may validate upto block n. Furthermore after validation you can prune
transactions spent until block n.
You would approach the highest block with validation and stop pruning say 100
blocks b
I hope I'm not thread-jacking here, apologies if so, but that's the approach
I've taken with the node I'm working on.
Headers can be downloaded and stored in any order, it'll make sense of what the
winning chain is. Blocks don't need to be downloaded in any particular order
and they don't need t
I understand the theoretical benefits of multi-sig. But if you want
to make this mind-numbingly simple, do it on the *existing* single-sig.
But why in the world do we not have a *business* that offers bitcoin
wallet insurance? The bitcoin world (and this list) ran around blaming
MtGox and users fo
You have to load headers sequantially to be able to connect them and determine
the longest chain.
Blocks can be loaded in random order once you have their order given by the
headers.
Computing the UTXO however will force you to at least temporarily store the
blocks unless you have plenty of RAM
This is beyond ridiculous...
Color kernel which works with padding is still quite simple. I think we
have extra 10-50 lines of code to handle padding in coloredcoinlib.
Essentially we have a couple of lines like this :
value_wop = tx.outputs[oi].value - padding
(value_wop means "value withou
I have to play dissenter here again..
Using a bitcoin address as a persistent identity key is the first real-world
use of Bitcoin that I can imagine will make it a 'killer app' that everyone
and their grandma will want to use.
If you think 'certificates' are a good solution, then there is some wa
Or have blocks distributed through pruned nodes as a DHT.
2014-04-07 20:13 GMT+01:00 Mark Friedenbach :
>
>
> On 04/07/2014 12:20 PM, Tamas Blummer wrote:
>> Validation has to be sequantial, but that step can be deferred until the
>> blocks before a point are loaded and continous.
>
> And how do y
On Mon, Apr 7, 2014 at 8:50 PM, Tamas Blummer wrote:
> You have to load headers sequantially to be able to connect them and
> determine the longest chain.
>
The isn't strictly true. If you are connected to a some honest nodes, then
you could download portions of the chain and then connect the v
2014-04-07 21:08 GMT+01:00 Troy Benjegerdes :
> I have to play dissenter here again..
>
> Using a bitcoin address as a persistent identity key is the first real-world
> use of Bitcoin that I can imagine will make it a 'killer app' that everyone
> and their grandma will want to use.
>
I am of the s
On Mon, Apr 7, 2014 at 2:48 PM, Tier Nolan wrote:
>> Blocks can be loaded in random order once you have their order given by
>> the headers.
>> Computing the UTXO however will force you to at least temporarily store
>> the blocks unless you have plenty of RAM.
> You only need to store the UTXO set
This is toying with the economics of cryptofinance in a way that needs to
be understood before being put under consideration for implementation in
Bitcoin. This is an opportunity for an altcoin to explore the implications
of these proposals prior to changing the properties of an already
precarious
On Mon, Apr 7, 2014 at 10:55 PM, Paul Lyon wrote:
> I actually ask for headers from each peer I'm connected to and then dump
> them into the backend to be sorted out.. is this abusive to the network?
>
I think downloading from a subset of the peers and switching out any slow
ones is a reasonabl
I actually ask for headers from each peer I’m connected to and then dump them
into the backend to be sorted out.. is this abusive to the network? I’m
concerned about that as I work on this, it only dawned on me the other night
that I really shouldn’t use the seed peers for downloading…
I figur
>
> I'd be fine with changing the key fingerprint algorithm to something else. Do
> you like CRC16?
>
I like CRC16. Do you intend to use it in conjunction with a cryptographic hash?
Regarding the choice of fields, any implementation of this BIP will
need big integer arithmetic to do base-58 anyw
On Mon, Apr 7, 2014 at 5:33 PM, Nikita Schmidt
wrote:
> Regarding the choice of fields, any implementation of this BIP will
> need big integer arithmetic to do base-58 anyway.
Nah, it doesn't. E.g.
https://gitorious.org/bitcoin/libblkmaker/source/eb33f9c8e441ffef457a79d76ceed1ea20ab3059:base58.c
On Monday, 7 April 2014, at 5:38 pm, Gregory Maxwell wrote:
> On Mon, Apr 7, 2014 at 5:33 PM, Nikita Schmidt
> wrote:
> > Regarding the choice of fields, any implementation of this BIP will
> > need big integer arithmetic to do base-58 anyway.
>
> Nah, it doesn't. E.g.
> https://gitorious.org/bit
On Mon, Apr 7, 2014 at 6:46 PM, Matt Whitlock wrote:
> On Monday, 7 April 2014, at 5:38 pm, Gregory Maxwell wrote:
>> On Mon, Apr 7, 2014 at 5:33 PM, Nikita Schmidt
>> wrote:
>> > Regarding the choice of fields, any implementation of this BIP will
>> > need big integer arithmetic to do base-58 an
Multi-sig requires infrastructure. It isn't a magic wand that we can
wave to make everyone secure. The protocols and techniques necessary
don't exist yet, and apparently no one has much of an incentive to
create them.
I mean no offense, and I don't mean to pick on you. Your post stuck out
w
On Fri, Apr 4, 2014 at 10:56 AM, Eric Larchevêque wrote:
> Yes, but no one will ever install a plug in.
This is quite true. I said the same about KryptoKit. Incredibly cool
to do bitcoin + PGP in client... but ultimately plugins reach 0.01%
of the user population.
--
Jeff Garzik
Bitcoin core
Being Mr. Torrent, I've held open the "80% serious" suggestion to
simply refuse to serve blocks older than X (3 months?).
That forces download by other means (presumably torrent).
I do not feel it is productive for any nodes on the network to waste
time/bandwidth/etc. serving static, ancient data
71 matches
Mail list logo
