On Tuesday, February 28, 2012 11:48:39 AM Pieter Wuille wrote:
> A simple way to fix this, is adding an extra protocol rule[1]:
>
> Do not allow blocks to contain a transaction whose hash is equal to
> that of a former transaction which has not yet been completely spent.
>
> I've written about
Please review and comment/critique:
https://en.bitcoin.it/wiki/BIP_DRAFT:_getmemorypool
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is
On Friday, March 02, 2012 1:51:41 PM Amir Taaki wrote:
> It is a implementation-specific non-bitcoin-protocol proposal. My
> understanding of BIPs is that they apply across bitcoin implementations
> and largely focus on the most generic use-cases (like the URIs) and the
> protocol. Things which aff
On Saturday, March 03, 2012 8:44:45 AM Stefan Thomas wrote:
> I have some comments on the content of the BIP, but since this thread is
> more of a meta-discussion I'll wait until the BIP is officially proposed.
Please do comment on the content, in the original thread if you prefer:
Message-Id: <2
On Saturday, March 03, 2012 9:23:08 AM Stefan Thomas wrote:
> From what I understand the BIP uses a polling model, e.g. a miner would
> use getmemorypool to request new work from a pool in intervals. Would it
> make sense to specify a version of the API supporting long polling?
You mean explicitl
On Saturday, March 03, 2012 10:05:58 AM Gavin Andresen wrote:
> > HTTP and JSON-RPC are a client-server model; there is no way for the
> > server to make calls to the client. It's not practical to expect clients
> > to run their own JSON-RPC server - many cannot listen on WAN ports at
> > all.
>
>
On Saturday, March 03, 2012 6:51:34 PM Geir Harald Hansen wrote:
> Long polling as currently implemented in pools has a race condition.
> Does the miner reconnect first or does another block change happen
> first? "Double" block changes are common with merged mining and I'm
> doing all sorts of tri
BIP16: 37% support vs 4% oppose
BIP17: 4% support vs 0% oppose
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio,
On Tuesday, March 06, 2012 12:34:15 PM slush wrote:
> is there any status update from Deepbit? Why he still does not support
> anything...
I think nobody has discussed P2SH with Tycho recently, since the priority is
to get BIP 30 deployed first.
--
On Tuesday, March 13, 2012 2:06:38 PM Mike Hearn wrote:
> https://github.com/bitcoin/bitcoin/pull/932 adds a "pong" message that
> echoes back a 64 bit nonce contained in the ping, if the protocol
> version is new enough.
>
> The goal of this is to make it easier for clients, especially mobile
> c
On Sunday, March 18, 2012 10:04:27 AM Amir Taaki wrote:
> Is this an accurate and precise summary of the changes needed for P2SH and
> BIP 16?
You might find my 0.4.x backport helpful:
https://github.com/luke-jr/bitcoin/commit/bip16_0.4.x
Be aware, this still needs auditing (nobody el
On Thursday, March 22, 2012 1:13:13 AM Eric Lombrozo wrote:
> I would like to propose adding these callback hooks to the main
> branch. I am willing to help locate these key points, reorganize the
> code to place these methods in separate source files, define a callback
> mechanism, and contribute
NOTE: I've been piecing this together for about a week now, and intended to
update it when 0.6.0 final was released, but with the timing of it, I just
won't get the time to update for a while, so here is my last draft...
It seems to me, there is potentially enough ready to merge into 0.7 to star
On Monday, April 02, 2012 4:55:03 PM Alan Reiner wrote:
> Any thoughts? (I have no doubts that there are :) )
IMO, the sign-request URI should be an extension on the existing bitcoin: URI
scheme; this way, sigNeeded can be omitted to imply "sign with a sending
address".
---
On Tuesday, April 03, 2012 2:46:17 PM Gavin Andresen wrote:
> We should avoid reinventing the wheel, if we can. I think we should
> extend existing standards whenever possible.
I wonder if it's possible to make sigs compatible with PGP/EC ?
On Wednesday, April 11, 2012 11:32:18 AM Mike Hearn wrote:
> Jeff asked for a BIP for the pong message, so here it is:
>
> https://en.bitcoin.it/wiki/BIP_0031
I thought we were going with 60001 for the protocol version bump?
---
On Wednesday, May 02, 2012 9:22:42 AM Mike Hearn wrote:
> The original software written by Satoshi Nakamoto, the project's founder.
This is just wrong. While Bitcoin-Qt is by far the best client, it is
Wladimir's, not Satoshi's.
> If your computer is low powered or you aren't willing to tolerate
On Wednesday, May 02, 2012 12:21:13 PM grarpamp wrote:
> Can someone also please set the reply-to header
> for these lists. It's really annoying to hit reply and
> not have the list address show up. Thanks :)
Try "Reply to All"
-
On Wednesday, May 02, 2012 3:34:35 PM Gary Rowe wrote:
> Bitcoin-Qt
> * Developed in C
This is far less relevant than license...
> Armory
> * Requires the entire blockchain
> * Dependent client of Bitcoin-Qt
Or bitcoind?
> Electrum
> * Dependent client of Bitcoin-Qt (on server)
Dependent on ce
I have finally got around to revising the BIP 22 draft, and would appreciate
further review: https://en.bitcoin.it/wiki/BIP_0022
I believe this revision addresses Geir's last email in March, as well as some
practical problems some pools recently came across.
To summarize the changes from the la
On Wednesday, May 16, 2012 6:18:27 PM Jeff Garzik wrote:
> Instead of further overloading service bits in the version message, or
> altering the version message, let us instead make feature discovery an
> easy, flexible, extensible process.
>
> We can add new commands without impacting older nodes
On Wednesday, May 16, 2012 6:38:28 PM Jeff Garzik wrote:
> On Wed, May 16, 2012 at 2:29 PM, Luke-Jr wrote:
> > That assumes you already have a connection to the peer in question.
> > As I understand it, the service bits are propagated as part of the
> > address, so you can
On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote:
> There appears to be some non-trivial mining power devoted to mining
> empty blocks. Even with satoshi's key observation -- hash a fixed
> 80-byte header, not the entire block -- some miners still find it
> easier to mine empty blocks, rathe
On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote:
> Comments? It wouldn't be a problem if these no-TX blocks were not
> already getting frequent (1 in 20).
FWIW, based on statistics for Eligius's past 100 blocks, it seems 10% (1 in
10) of 1-txn blocks is not actually unreasonable. This als
On Friday, May 25, 2012 12:51:09 AM Jeff Garzik wrote:
> On Thu, May 24, 2012 at 8:45 PM, Luke-Jr wrote:
> > On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote:
> >> Comments? It wouldn't be a problem if these no-TX blocks were not
> >> already getting f
On Tuesday, May 29, 2012 8:52:49 AM Michael Grønager wrote:
> The format of the sla.php page should then be specified too - but it could
> be a json-rpc call returning a json object like (as result): {
> sla_version: "0.1",
> accept_no_fee_tx: false,
> min_fee: 5,
> big_tx_fee:
On Tuesday, May 29, 2012 3:05:18 PM Peter Vessenes wrote:
> 1) Germane to the original conversation, anything hard to implement will
> not get implemented by miners.
Without my got-tired-of-waiting-for-someone-to-merge-it coinbaser branch,
anything modifying the coinbase is hard to implement.
>
On Tuesday, May 29, 2012 3:28:56 PM Peter Vessenes wrote:
> I don't understand what the 20 byte keyhash is. Can you elucidate?
20 byte keyhashes are a fundamental building block of the Bitcoin protocol.
ripemd160(sha256(ecdsaPubKey))
--
On Tuesday, May 29, 2012 3:36:34 PM Peter Vessenes wrote:
> I suppose I mean that I don't understand how to reverse that into a URL
> when one is presented only with a block, or perhaps a coinbase in a
> transaction.
A new message can be added to the p2p relay network, similar to tx and alert
bro
Analysis, comments, constructive criticism, etc welcome for the following:
==Background==
At present, an attacker can harm a pool by intentionally NOT submitting shares
that are also valid blocks. All pools are vulnerable to this attack, whether
centralized or decentralized and regardless of rew
On Monday, June 04, 2012 1:43:42 AM Peter Vessenes wrote:
> Does it have asymmetric payoff for an attacker, that is, over time does it
> pay them more to spend their hashes attacking than just mining?
That depends on the pool's reward scheme. Some complicated forms are capable
of getting "bonus"
On Monday, June 04, 2012 8:49:48 PM Mike Koss wrote:
> As I understand the attack, the attacker gets compensated for the shares
> they earn, but the pool will be denied any valid blocks found. The
> attacker DOES NOT have access to the Bitcoins earned in the unreported
> block (only the mining poo
On Tuesday, June 05, 2012 12:00:25 AM Mike Koss wrote:
> I don't understand how your proposal will work for decentralized pools -
> can you explain it more concretely?
>
> What would the new block header look like?
For example (just a draft; in reality, merged mining would probably be
Block 177618 was rejected by BIP16-enabled backports (0.4.x and 0.5.x) due to
containing a P2SH redemption with over 200 bytes in. Since the BIP16 code uses
IsPushOnly to check the scriptSig for compliance, and IsPushOnly in these
versions also enforced the 200-byte "is standard" rule, they were
On Saturday, June 16, 2012 11:39:00 PM Gregory Maxwell wrote:
> On Sat, Jun 16, 2012 at 5:41 PM, Gavin Andresen
wrote:
> > RE: 0x06/0x07 'hybrid' public keys:
> >> Any opinions? Forbidding it certainly makes alternative implementation
> >> slightly easier in the future, but I'm not sure the hassl
On Sunday, June 17, 2012 11:04:42 PM grarpamp wrote:
> >> https://github.com/bitcoin/bitcoin
> >> https://git.gitorious.org/bitcoin/bitcoind-stable
> >
> > The latter is Luke's backports of security and stability fixes to
> > otherwise unmaintained old versions.
>
> Ah ok, coming from cvs/svn, it
On Monday, June 18, 2012 3:27:52 AM grarpamp wrote:
> So I get that github/master is the obvious top of things.
> But in looking at where the tags are between repositories,
> it's still not clear to me what the workflow is.
Workflow is all new development takes place in master during release windo
On Monday, June 18, 2012 8:09:56 AM grarpamp wrote:
> > I guess I've been neglecting to update the stable repo with
> > releases tagged in master. It should be fixed now.
>
> Yes, that has helped! Now git'ers can easily compare the release
> tags to stable 'x' branches on gitorious. I don't know h
FWIW, all this argumenting is why my original suggestion for a Clients list
focussed on objective information in alphabetical order.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's
https://en.bitcoin.it/wiki/Clients
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will incl
On Monday, July 16, 2012 11:47:02 PM Jeff Garzik wrote:
> Vladimir does raise a fair point, though. Hackathon seems appropriate
> for bitcoin.org as it is focused on dev-related activities. (full
> disclosure: speaking at bitcoin2012.com) The conference might or
> might not be. The conference d
It just occurred to me that the block version number could easily be used as a
cheap "extra nonce" right now. Considering that we will probably see lots of
ASIC miners running at 1 TH/s per rig before the end of 2012, it might be
desirable to save the block version for this purpose.
The current
be
> fetched from disk. Which isn't a huge deal, unless we start
> aggressively pruning spent transactions, and that coinbase 900 blocks
> back got spent and pruned.
Any reason CBlockIndex couldn't cache the coinbase version?
> On Sun, Jul 22, 2012 at 4:52 PM, Luke-Jr wrote:
On Friday, July 27, 2012 5:59:20 AM grarpamp wrote:
> > I now have an 1.8 ghz p3 celeron (128k cache) which should be
> > substantially slower than your machine, running vintage 2.6.20 linux.
> > Unfortunately I forgot to turn on timestamp logging so I don't know
> > how long it took to sync the ch
On Sunday, July 29, 2012 10:17:51 AM Mike Hearn wrote:
> I guess Gavin would be the final signer.
Considering that Gavin is not interested in participating in any way in the
stable versions, I would prefer to see someone else responsible for OS-vendor
signing.
-
On Monday, July 30, 2012 8:26:12 PM Amir Taaki wrote:
> https://en.bitcoin.it/wiki/BIP_0022
Note that the Pooled Mining parts have already been moved to:
https://en.bitcoin.it/wiki/BIP_GMPPM
It just needs a number assigned (as the last part).
-
Make IPv6 support optional again (defaults
> to enabled)
> luke-jr https://github.com/bitcoin/bitcoin/pull/1431
>
> 11) MAYBE: getblocktemplate ('getmemorypool', post IRC debate)
> luke-jr https://github.com/bitcoin/bitcoin/pull/936
+
+ m) getmemorypool: longpolling support
+ l
On Saturday, August 11, 2012 4:43:28 PM Geir Harald Hansen wrote:
> By the way, by far the most common support request I have at my pool is
> users withdrawing coins and not seeing it in their wallet because it's
> not up-to-date with the block chain. Might be worth adding something in
> the bitcoi
On Wednesday, August 22, 2012 2:25:20 AM Forrest Voight wrote:
> An unpatched Bitcoin installation can be permanently wedged at its
> current highest block using this and the fact that Bitcoin caches
> orphan blocks in a disk-backed database. To do so, the attacker must
> send it a valid block (tha
On Monday, September 10, 2012 3:07:52 PM Matthew Mitchell wrote:
> Here is a BIP draft for improving the block relaying and validation so that
> it can be done in parallel and so that redundancy can be removed. This
> becomes more beneficial the larger the block sizes are.
>
> https://en.bitcoin.i
On Wednesday, September 26, 2012 11:41:13 AM Daniel F wrote:
> on 09/26/2012 01:49 AM Wladimir said the following:
> > I'm willing to write this. But I know these kinds of proposals always
> > end in a big discussion about what should be and what should not be on
> > bitcoin.org, however we should
On Sunday, October 14, 2012 8:52:33 PM Kyle Henderson wrote:
> Given that sourceforge has shown to restrict access to a number of
> countries at the request of the USA
This needs some clarification. If the USA has "requested" it, then presumably
there's some legality involved, and our US develope
On Tuesday, November 06, 2012 6:47:34 PM Gavin Andresen wrote:
> Thursdays at 18:00 UTC (6PM Europe/1PM east US/10AM west US) seem to
> be a good time for the core dev team to meet on the #bitcoin-dev
> freenode IRC channel to chat.
>
> I'd like to talk about:
>
> o Can we put together a TODO lis
On Tuesday, November 06, 2012 7:56:23 PM slush wrote:
> On Tue, Nov 6, 2012 at 7:13 PM, Luke-Jr wrote:
> > But more important to the success of BIP today, I think, is encouraging
> > wider community participation.
>
> It's not about BIP process, it's possi
On Monday, November 26, 2012 11:02:14 PM Mike Hearn wrote:
> Minor caveat, IMHO we should support all CAs used by the popular
> browsers.
I would prefer using the user-accepted certs at the operating system level...
--
Mo
On Monday, November 26, 2012 11:16:03 PM Mike Hearn wrote:
> They could be included as well of course, but from a seller
> perspective the most important thing is consistency. You have to be
> able to predict what CAs the user has, otherwise your invoice would
> appear in the UI as unverified and i
On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote:
> Obviously the state of the world with browsers is not that good... but
> in our own UAs we can do better and get closer to that.
This effectively centralizes Bitcoin (at least in the eyes of many) and even
if each competing client
On Tuesday, November 27, 2012 12:02:42 AM Rick Wesson wrote:
> Another nifty thing is that it can associate a cert to a domain and a
> payment address, if one were to put said address in the DNS :)
>
> Now I am sure the majority of the bitcoin user-base desires anonymity,
> but as a merchant I wou
On Tuesday, November 27, 2012 12:16:07 AM Gregory Maxwell wrote:
> On Mon, Nov 26, 2012 at 6:44 PM, Luke-Jr wrote:
> > On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote:
> >> Would you find it acceptable if something supported a static whitelist
> >> plus
On Friday, February 08, 2013 11:49:09 PM Gavin Andresen wrote:
> Windows builds are varying with every compile, and I think I finally
> figured out why: we are not passing the -frandom-seed flag down into
> the leveldb build (I used objdump to dump two different binaries, and
> they differed only i
On Saturday, February 09, 2013 2:33:25 PM Timo Hanke wrote:
> > Why don't you use namecoin or another alt-chain for this?
>
> Because namcoin tries to solve a different problem, DNS, whereas I want
> to establish an identity for a payment protocol.
What is the technical difference here? Namecoin
On Monday, March 11, 2013 7:27:51 PM Rune K. Svendsen wrote:
> From: "Rune K. Svendsen"
>
> On the Main tab in the Options dialog, it previously said a minimum
> fee of 0.01 is recommended. This amounts to about $0.50 at today's
> price. Change this to 0.001 to be more sensible. We could even go
On Monday, March 11, 2013 9:17:25 PM Rune Kjær Svendsen wrote:
> On Mon, Mar 11, 2013 at 9:46 PM, Luke-Jr wrote:
> > On Monday, March 11, 2013 8:34:52 PM Rune Kjær Svendsen wrote:
> > > Ok. I'll fork on Github. Looking at the source, and some Qt
> >
> > doc
On Tuesday, March 12, 2013 7:03:54 AM Alan Reiner wrote:
> I'm sure it won't be long before Slashdot and a variety of sources start
> reporting on this event. Bitcoin has been in the media a lot lately, so
> this story is likely to get some attention. The blowback of this event
> is mostly psycho
On Tuesday, March 12, 2013 9:47:00 AM Peter Todd wrote:
> We can allow for transaction replacement for the purpose of adding fees
> to existing transactions safely, and while not increasing the risk of
> double-spends by taking advantage of the stubbed out replacement code.
Side note: Adding fees
Here's a simple proposal to start discussion from...
BEFORE block 262144:
- Never make a block that, combined with the previous 4 blocks, results in
over 4500 transaction modifications.
- Reject any block that includes more than 4500 transaction modifications on
its own (slight soft-fork)
- (the
r controversial changes.
I figured 2 MB in 2-3 years was fairly uncontroversial.
If not, let's scrap that idea for now.
> Luke-jr, any chance in getting you to revise your proposal to narrow
> the scope to things that don't need serious debate?
It was a one-time "start the
ion of patched clients *is by definition* a
hard fork.
> Proposal:
>
> 1) Patch the pre-0.8 branches to support an increased lock count, whatever
> number is required to make sure that this problem never shows up again at
> the current block size (I defer to Luke-Jr and gmaxwell&#
On Wednesday, March 13, 2013 6:01:02 PM Michael Gronager wrote:
> Please note that it was not 0.8 that had issues, but 0.7(and downwards).
While 0.7 and earlier do have issues, they also define the Bitcoin protocol.
0.8's failure to comply with the protocol is an issue.
On Wednesday, March 13, 2013 6:27:13 PM Mark Friedenbach wrote:
> Luke-Jr is suggesting that we add-to/modify the bitcoin protocol rules
> which all verifying implementations must adhere to. I'm suggesting that we
> instead change the old codebase to do what we expected it to do all
On Wednesday, March 13, 2013 9:06:44 PM Andy Parkins wrote:
> On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote:
> > Here's a simple proposal to start discussion from...
>
> It seems to me that the biggest failure was not the development of two
> chains, but the assurance
On Friday, March 15, 2013 5:06:20 PM Benjamin Lindner wrote:
> On Mar 13, 2013, at 8:18 PM, Cameron Garnham wrote:
> > For me, everyone signed up to bitcoin thinking that there was a 1MB /
> > block limit. The lock limits were unexpected, and could be considered
> > extremely uncontroversial to r
On Sunday, March 17, 2013 2:20:14 AM Frank F wrote:
> Well, he did make the bitcoin.org/may15.html page already. It would be
> crazy to change that now.
OTOH, the page's recommended config isn't really too ideal. While the new lock
limit should be good for up to 2 block deep reorgs, I doubt merch
On Saturday, March 23, 2013 10:42:26 AM Randy Willis wrote:
> Introducing super-nodes with thousands of connected peers can greatly help
> here.
UDP is connectionless.
I would hope any UDP bitcoin protocol doesn't try to emulate a connection. :/
Luke
-
On Saturday, March 23, 2013 4:16:19 PM Jeff Garzik wrote:
> Users should not be impacted. Some ancient miners will produce
> newly-invalid blocks (v1), that will get ignored. The easy solution
> is to mine using a recent bitcoind (0.7 or later). If you are a miner
> and need help upgrading to v2
On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote:
> On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr wrote:
> > I don't think anyone is mining using bitcoind 0.7 or later?
>
> slush, BTC Guild, ozcoin too I think, several others.
Not for producing coinbases (where B
On Saturday, March 23, 2013 5:47:46 PM Jeff Garzik wrote:
> On Sat, Mar 23, 2013 at 1:43 PM, Luke-Jr wrote:
> > On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote:
> >> On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr wrote:
> >> > I don't think anyone is
On Saturday, March 23, 2013 6:21:32 PM Jeff Garzik wrote:
> On Sat, Mar 23, 2013 at 1:51 PM, Luke-Jr wrote:
> > bitcoind is nowhere in the implementation of the miner end of BIP 34.
>
> Again, not strictly true.
>
> bitcoind's 'getblocktemplate' RPC
On Sunday, April 14, 2013 5:09:58 AM Peter Todd wrote:
> Currently signmessage/verifymessage only supports messages signed by a
> single key. We should extend that to messages signed by n-of-m keys, or
> from the users point of view, P2SH multisig addresses.
I think it would be wise to figure out
https://bitcointalk.org/?topic=205878
This encoding is designed so that it could replace Base58Check in new data,
with the following goals in mind:
- Impossible(?) to manipulate without completely changing it
- Clearly identifiable prefix, regardless of data size
- Cheaper to process (simpler and
This sounds similar to the "bitcoin2" branch I created a while back -
basically a "next"-like branch, but for hardforking changes that refused to
run without the -testnet option. There's so much non-hardforking code that can
be written/tested, at this point, that I think it was and maybe is prem
Bitcoin currently uses raw hashes extensively as UUIDs; whether the payment
protocol should be influence by that or not, I've not given thought to yet.
Some alt coins may share a blockchain, or even merely the genesis block (two
currently do; despite one of those being a scamcoin, I think the po
On Wednesday, May 22, 2013 2:20:22 PM Jeff Garzik wrote:
> On Wed, May 22, 2013 at 10:12 AM, Melvin Carvalho
>
> wrote:
> > On 22 May 2013 16:07, Jeff Garzik wrote:
> >> On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho
> >>
> >> wrote:
> >> > Some out of band algo/hash could work so long as th
On Saturday, May 25, 2013 3:36:46 AM Robert Backhaus wrote:
> Here is the link to the FreeBSD build system 'port' that I am planning to
> get committed when 0.8.2 is released. Any comments appreciated.
>
> The Makefile mostly just applies the users request for GIU/QR/UPNP. The
> major change is us
On Saturday, May 25, 2013 8:25:35 AM Melvin Carvalho wrote:
> It might be an idea to have 'rule change' fixes and 'bug fix' releases go
> out separately
Bitcoin is a consensus system. You can't run clients with different rules on
the same blockchain/network - it just won't work! Maybe we're now t
On Thursday, May 16, 2013 10:02:05 AM bitcoingr...@gmx.com wrote:
> One of the main goals will be to separate the wallet from the node, as we
> have already done with mining.
How is this different from what Electrum has already done?
Luke
-
On Thursday, May 16, 2013 10:55:44 AM Addy Yeow wrote:
> Is the number representing the count for the client nodes?
>
> I was curious of the count myself earlier this week and started to
> traverse down the network using getaddr message starting from seed
> nodes and found upward to 57k nodes runn
On Thursday, May 30, 2013 2:54:00 AM grarpamp wrote:
> Should there not be a 0.8.2 branch laid down at 09e437b (v0.8.2)
> in which the like of release build stoppers or critfixes such as d315eb0
> are included... for those tracking that level of defect without
> wishing to track all the growing pos
On Saturday, June 01, 2013 7:30:36 PM Peter Todd wrote:
> scriptPubKey: OP_TRUE
>
> ...
> Along with that change anyone-can-spend outputs should be make IsStandard()
> so they will be relayed.
Data does not belong in the blockchain. People running nodes have all
implicitly agreed to store the b
> and it covers the size of the transaction, why would it matter if it is not
> a payment?
See above.
> I could be totally misreading this thread, too, so please allow me some
> slack if I have!
>
> On Thu, Jun 6, 2013 at 12:14 PM, Luke-Jr wrote:
> > On Saturday, June 01,
On Thursday, June 06, 2013 8:16:40 PM Andreas M. Antonopoulos wrote:
> > This doesn't work like you might think: first of all, the fees today are
> > greatly subsidized - the actual cost to store data in the blockchain is
> > much higher than most storage solutions. Secondly, only the miner receive
On Monday, June 10, 2013 9:09:13 PM Peter Todd wrote:
> # Protocol Work
This is basically done.
> Basic idea is the miner makes two connections, their pool, and a local
> bitcoind.
>
> They always (usually?) work on the subset of transactions common to both
> the pool's getblocktemplate and thei
On Tuesday, June 11, 2013 1:11:33 PM Melvin Carvalho wrote:
> For the sake of argument let's say that opaque means that you can tell
> nothing about the address by examining the characters.
This is true or false based on CONTEXT.
Obviously, an implementation of transaction handling (eg, wallets)
On Friday, June 14, 2013 8:06:54 PM Peter Todd wrote:
> On Mon, Jun 10, 2013 at 09:23:14PM +0000, Luke-Jr wrote:
> > Might as well just use higher difficulty shares (each one audited) for
> > the same effect. Block proposals allow the miner to tell the pool its
> > transactio
Note that the "earn a mixture of BTC and TBC, but not both in full volume"
only works for TBC because the price is by definition fixed with BTC.
I'm not sure how you could implement something like this for an altcoin where
the price is floating independently of Bitcoin.. that is, how you would kn
Timestamping ("proof of existence") doesn't need a coin at all. Just collect
all the hashes you need timestamped into a PoE merkle tree and add that to the
merged mining MT. It's pretty simple and straightforward, just needs someone
to implement it.
On Saturday, June 15, 2013 12:09:09 AM Dennis
On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote:
> * Very real possibility of an overall net reduction of full nodes on P2P
> network
Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or
MultiBit node. :/
Jim, will MultiBit be adding p2p listening support?
> I'
On Sunday, July 14, 2013 7:22:10 PM John Dillon wrote:
> > Merged mining is not mining the coin for free. The total reward (ie
> > btc + frc + nmc + dvc) should tend to equal the mining costs. But the
> > value comes from demand, not costs. So if people demand it more it
> > price will rise no matt
On Sunday, July 14, 2013 7:42:06 PM Pieter Wuille wrote:
> On Sun, Jul 14, 2013 at 07:33:06PM +0000, Luke-Jr wrote:
> > > The issue is that unless there is a cost to mining a *invalid* block
> > > the merge mined coin has little protection from miners who mine invalid
On Monday, July 15, 2013 12:12:23 AM Peter Todd wrote:
> On Sun, Jul 14, 2013 at 08:16:41PM +0000, Luke-Jr wrote:
> > P.S. How about a Zerocoin with no-reward/PoSacrifice merged mining as
> > well as (rewarded) Prime POW; maybe with no subsidy halving, to try a
> > new
1 - 100 of 281 matches
Mail list logo
