On Monday, August 29, 2011 4:10:01 PM Gavin Andresen wrote:
Other things on the 0.4 TODO list:
Can we get some form of the signmessage method in?
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a
Hi,
Bitcoin-qt is now feature complete (including wallet encryption), and has
been tested for a while by various people without any major problems.
It is now in status of feature freeze.
The project builds on Windows, MacOSX and Linux using qmake.
Impact to the core bitcoin functions is still
Bitcoin version 0.4 release candidate 1 is ready for initial testing;
please grab the source from github and try to break it.
The big, visible change is wallet private key encryption, which is NOT
turned on by default.
The big, invisible change is a reworking of internal critical section
mutexes
Given that there was not a single response to my post, I gather there is
no to little interest in an updated MinorFs that could be used by bitcoin
on systems that support AppArmor (Ubuntu and OpenSuse).
Nevertheless I've put down the initial set of specs for a rewrite of
MinorFs for if anyone
On Fri, Sep 2, 2011 at 8:32 PM, Rob Meijer capib...@xs4all.nl wrote:
Given that there was not a single response to my post, I gather there is
no to little interest in an updated MinorFs that could be used by bitcoin
on systems that support AppArmor (Ubuntu and OpenSuse).
Oh yes there is
On Fri, Sep 2, 2011 at 8:12 PM, Gavin Andresen gavinandre...@gmail.comwrote:
Bitcoin version 0.4 release candidate 1 is ready for initial testing;
please grab the source from github and try to break it.
The big, visible change is wallet private key encryption, which is NOT
turned on by
Once more before I just give up on trying...
These branches fix bugs still remaining in 0.4rc1:
- bugfix_getwork_newblk_race
- getwork_dedupe
- boost_fs3
- gitignore
Additionally, this branch adds a tolerance to human error typing in base58
with ambiguous symbols, and should be very safe to
On Sat, 2011-09-03 at 20:13 -0400, Gavin Andresen wrote:
Quick status update on 0.4; I probably won't have time to tackle these
properly before Tuesday:
+ sipa found what looks like a deadlock between the addr-handling and
IRC-join-handling code.
+ UukGoblin reports a deadlock problem on a
On Sat, Sep 03, 2011 at 08:13:14PM -0400, Gavin Andresen wrote:
Quick status update on 0.4; I probably won't have time to tackle these
properly before Tuesday:
+ sipa found what looks like a deadlock between the addr-handling and
IRC-join-handling code.
I've compiled bitcoind with Gavin's
(Moving here because forum thread at
https://bitcointalk.org/index.php?topic=39088 didn't yield much
discussion)
Pull request: https://github.com/bitcoin/bitcoin/pull/476
Diff: https://github.com/bitcoin/bitcoin/pull/476/files
This was originally a patch that returned bitcoin's memory pool as
Sorry, by bad - first clean checkout for quite a while (must have changed it
earlier myself...).
/M
On 05/09/2011, at 14:42, Luke-Jr wrote:
On Monday, September 05, 2011 3:25:47 AM Michael Grønager wrote:
Findings - compile (I do not use the UPNP feature):
in the makefile.unix I have to
While I'm asking questions I'll add one more regarding the getaddr
message.
Talking to myself here. I just sent this message then found this
brilliant set of articles in the Dev Tech forum which answers the
question very nicely: *https://bitcointalk.org/index.php?topic=41722.0
On Sun, Sep 4, 2011 at 13:59, Pieter Wuille
pieter.wui...@cs.kuleuven.be wrote:
I've compiled bitcoind with Gavin's DEBUG_LOCKORDER, and fixed two potential
reported deadlock issues (see
https://github.com/sipa/bitcoin/commits/lockfixes).
My mistake: these are not actual potential deadlocks,
Actually Steve, take a look at the bitcoinj mailing list today. Somebody has
already built this and has it running. It's accumulating data at the moment,
they'll announce it more widely soon. But I think there's no need to
duplicate work.
I've got minna patches for nio based on bitcoinj. I've enumerated the
network a few times and am working on a DNS seed service as well as some
weather reports.
Happy to start a branch when the committers are ready.
-rick
On Tue, Sep 6, 2011 at 12:42 AM, Steve shadders@gmail.com wrote:
Hi
Got a fix for the encrypted-wallet mining issue:
- unique_coinbase
It depends on (and merges) the getwork_dedupe fix already common on pools and
other miners who pay attention to the latest mining fixes.
To merge:
git fetch git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git \
4a/ Serialize all request/response exchanges. i.e. request comes in
from remote node, proxy aquires lock on the proxy-localdaemon channel
and sends request. Channel remains locked until response is received or
timeout (in which case remote node gets no response). Unlock channel
after
@Steve re Who knows, it might be the only way we'll ever hear from Satoshi
again.
That brings up a good point... Does anyone aside from Satoshi actually have
the ability to send such an alert? Should we at the very least change the
alert system to give such privileges to current devs and ensure
On Thursday, September 08, 2011 1:33:15 PM John Smith wrote:
Be careful though, if you relay everything, it suddenly *does* have DDoS
potential...
Maybe require a proof-of-work then?
--
Doing More with Less: The Next
On Thursday, September 08, 2011 3:45 PM, Luke-Jr l...@dashjr.org wrote:
I don't seem to recall this ever happening, despite Deepbit having over 50%
multiple times now.
An alert would have been issued if they had abused that position.
On Eligius, I have two bitcoinds running on the same system:
- a hub node, which is dedicated to relaying network activity between the
hundreds of nodes Eligius peers with
- a work node, which is dedicated to managing mining, and only ever connects
to the hub node
Lately, the hub node has
Resending to mailing list as I replied directly...
On Thu, Sep 8, 2011 at 11:03 PM, Christian Decker
decker.christ...@gmail.com wrote:
Will w...@phase.net wrote:
In fact, I think the alert system should relay (note, NOT display)
messages
*regardless of the key used*, so it isn't yet
I expect that I will make a lot of mistakes, and probably ask too many
questions - but I hope you can bear with me.
I've been trying to keep a low profile as I get better acquainted with the
project. I'm clearly in the company of some very smart people - and would
like to keep it that way.
I've
Hello Alex,
On Sun, Sep 11, 2011 at 12:20 AM, Alex Waters ampe...@gmail.com wrote:
Can you please submit a pull request and testing plan? If these already
exist, can you please link them here?
What testing plan do you need?
JS
Alex,
On Sun, Sep 11, 2011 at 7:45 AM, Alex Waters ampe...@gmail.com wrote:
Hey John,
It could be as simple as listing some things that you think could possibly
break if qt is implemented. For example, check the UI for artifacts. I
don't really know what could potentially need to be tested,
On Tuesday, September 13, 2011 10:43:27 AM Gavin Andresen wrote:
3) I'd really like to come to consensus on one or more
'multi-signature' standard transactions to enable much better wallet
backup and security.
More important in this area, IMO, is support for deterministic keychains in
A few thoughts:
Should the DoS protection auto-disable if the node has less than a
minimum number of connections? The idea being that if our node seems to
be kicking /everybody /off the roster maybe there is something wrong
with the protections.
It would be nice if the node sent a message
I hate to get specific about potential attacks on a public mailing
list, but I think the debate over what to do with non-standard
transactions means we need to.
I agree with Gregory; if there are NO rules about what transactions
peers can send at you, then an attacker can trivially get around
If I think you're trying to DoS me, why would I be nice to you?
The issue is, what if I'm not trying to DoS you, but something went wrong?
think response messages would just give an attacker another potential
attack vector, and it is clear from the debug.log what triggers a ban.
Only clear
Darn good question. If the protection fails, would it be better for it
to 'fail hard', leaving people complaining bitcoin won't stay
connected!
Or fail soft, so you at least have a couple of connections.
I think fail hard is better-- we'll immediately know about the
problem, and can fix
Gavin, Jeff, et al:
A group of developers would be interested in maintaining 0.4 into the future
as a stable branch (ie, bugfixes only). Would you be willing to plan on making
the next mainline version after 0.4, being called 0.5, so we can release
0.4.1, 0.4.2, etc? If we prepare the git
http://www.python.org/dev/peps/ is a good reference if you're
interested in seeing how PEPs work in action. I would be more than
willing to maintain a similar index if that's what people want.
Something to note is that Python does not use Git or GitHub (AFAIK).
So we would need to update 001 to
http://www.python.org/dev/peps/ is a good reference if you're
interested in seeing how PEPs work in action. I would be more than
willing to maintain a similar index if that's what people want.
Would the multi-signature proposal be a good test case for BEP-0002?
New 'standard' transaction forms would be perfect candidates for BEPS.
I think we aught to have a formal proposal to separate the protocol
version from the client version, too.
--
Does anybody besides me think maybe we should name them something
other than BEP ?
I'm worried we'll regret it in
What about this one?
@@ -1276,13 +1278,13 @@ bool CBlock::AcceptBlock()
// Get prev block index
mapuint256, CBlockIndex*::iterator mi =
mapBlockIndex.find(hashPrevBlock);
if (mi == mapBlockIndex.end())
-return error(AcceptBlock() : prev block not found);
+return
@@ -1276,13 +1278,13 @@ bool CBlock::AcceptBlock()
// Get prev block index
mapuint256, CBlockIndex*::iterator mi =
mapBlockIndex.find(hashPrevBlock);
if (mi == mapBlockIndex.end())
- return error(AcceptBlock() : prev block not found);
+ return DoS(10,
On Mon, Sep 26, 2011 at 3:42 PM, Nils Schneider n...@nilsschneider.net wrote:
I'd like to simplify the internal reference miner and remove all
dependencies on cryptopp (it's the only place we use cryptopp instead of
OpenSSL).
Unfortunately, cryptopp is also used to calculate getwork midstate.
Does this mean dispute mediation (2-of-3) will not be supported?
Not with this PULL-- I think wallet security and backup is a critical
feature, so that is what this is for.
I thought the plan was also to allow CHECKMULTISIG for smallish numbers of
keys.
groffer pointed out that might cause
On Fri, Sep 30, 2011 at 1:21 PM, Gavin Andresen gavinandre...@gmail.com wrote:
Accepting this does not preclude adding more 'standard' transaction
types in the future.
I think 2 of 3 is a _far_ more useful example than (a or b), it is
the prototype for a normal escrow transaction., and still
Hey,
The Zen of Python is relevant here: http://www.python.org/dev/peps/pep-0020/
In the face of ambiguity, refuse the temptation to guess.
If a node incorrectly implements the standard then it should be shunned
immediately. Not only is this more secure, but it will ensure long term
Hello Brian,
There are no unit tests for the Qt GUI code itself as of this moment.
The tests for the bitcoin core are still there in src/tests ). You need to
build them with the makefile, though. qmake is currently only used for the
GUI executable.
JS
On Mon, Oct 3, 2011 at 11:04 PM, Brian
I see the Contracts wiki page talking about,
1) Transactions passed around outside the P2P network ...
2) ... transaction ... not broadcast right away
How are transactions created, stored and transmitted? How will they
be brought back into the P2P network once they are out?
B
--
Make a Small
Hi !
I am looking into enabling a split between thin clients holding the wallet and
server(s) holding the blocks and txdb.
To that end I am considering to simplify the WalletTx a bit and I came across
the vtxPrev in the code. As I see it vtxPrev is only used for keeping a list of
supporting
I imagine a lot of the things on the contracts page will be implemented by
specialized software that interacts with the Bitcoin network directly.
Transactions would then be moved around, for example, by having clients do
HTTP POSTs of protocol buffers to servers that are listening and know how to
Bad update. Macports has a couple of boost packages. Install the newer 1.46
ones.
--
Douglas Huff
On Oct 5, 2011 1:43 PM, Gavin Andresen gavinandre...@gmail.com wrote:
I updated src/makefile.osx and doc/build-osx.txt today, assuming that
the MacPorts versions of dependencies will be used and
I added -mt and it compiles, but here is a surprise. I had to add
libz.a to the makefile.osx. Sounds odd! Its coming from the crypto
libs.
On Wed, Oct 5, 2011 at 11:50 AM, Douglas Huff dh...@jrbobdobbs.org wrote:
Bad update. Macports has a couple of boost packages. Install the newer 1.46
Brian,
Yea, I vaguely remember going through all this when I first tried building it.
If I recall you can statically link libz into crypto when you compile crypto.
Or something like that. Maybe the default MacPorts crypto install does not do
this.
Eric
--
Eric Mockensturm, Ph.D.
Reposting here from the forums:
Good news: I'm just about to get a Bitcoin-Qt version 0.5 Release
Candidate 1 out, with a much-improved GUI.
Bad news: all the translations for the old wxWidgets Bitcoin are
obsolete, and the process for making translations is different.
Is anybody willing to
Damn, german is already contributed :-)
Well I can still do the italian one and check german then.
On Sat, Oct 8, 2011 at 11:13 PM, Gavin Andresen gavinandre...@gmail.comwrote:
Reposting here from the forums:
Good news: I'm just about to get a Bitcoin-Qt version 0.5 Release
Candidate 1 out,
Hi!
I can translate it to Brazilian Portuguese.
Best,
Thiago
On 8 October 2011 18:13, Gavin Andresen gavinandre...@gmail.com wrote:
Reposting here from the forums:
Good news: I'm just about to get a Bitcoin-Qt version 0.5 Release
Candidate 1 out, with a much-improved GUI.
Bad news: all
Please at least get Coinbaser merged for 0.5. It has had a lot of testing on
Eligius for months, a landslide of support for the new JSON-RPC method (as
requested), and I have even gone to the effort to document it. As I will no
longer be using bitcoind for Eligius soon, I have little incentive
On Monday, October 10, 2011 5:22:28 AM Mike Hearn wrote:
On Sun, Oct 9, 2011 at 1:12 AM, Luke-Jr l...@dashjr.org wrote:
As I will no longer be using bitcoind for Eligius soon
What will you be using instead? Isn't bitcoind a requirement for running a
pool?
Writing some custom software
On Monday, October 10, 2011 9:18:07 AM Mike Hearn wrote:
As I will no longer be using bitcoind for Eligius soon
What will you be using instead? Isn't bitcoind a requirement for
running
a
pool?
Writing some custom software designed to more efficiently create work.
To
Reposting from the forums:
https://bitcointalk.org/index.php?topic=47586
I just tagged the git tree v0.5.0rc1. If you are able, please
compile and help test.
See the INSTALL file at the top of the source tree for instructions on
compiling. Binary releases for at least unix and mac should be
On Thursday, October 13, 2011 9:32:48 AM Gavin Andresen wrote:
• Tighten up block-time rules to fix the potential timejacking attack.
Once again, this does not fix anything (they're already strict enough for the
2-week window), and just creates new problems.
• Work on 'discouraging'
Amir started the get more formal about changes to bitcoin ball
rolling by creating BIP 0001, starting from the Python PEP /
BitTorrent BEP processes:
https://en.bitcoin.it/w/index.php?title=BIP_0001
The idea is to use BIPs for changes that may or will affect every
bitcoin implementation (not to
• I propose that BIPs be wiki pages, with a social convention that the
Author gets final word if any editing wars break out.
ACK
• If he's willing, I propose that Amir take the role of BIP editor.
ACK
• I think bitcoin is still too small to have a specialized
bitcoin-ideas mailing
On Thu, Oct 20, 2011 at 7:02 AM, Alex Waters ampe...@gmail.com wrote:
• I propose that BIPs be wiki pages, with a social convention that the
Author gets final word if any editing wars break out.
ACK
Does it have to be wiki pages if we're going through an editorial process
anyway, and there
And is anybody willing to take the job of coordinating translation
efforts, figuring out if Transifex is a good tool to use, and writing
some documentation to make it easy for people to create and submit new
translations?
I have exported all .ts to transifex.
Hi there!
As part of my green address endeavor, I'm currently trying to extend the
'gettransaction' call to include an extra field inputaddresses which
should return a list of the Bitcoin addresses associated with the inputs
of the transaction.
I understand that this is not generally possible,
On Mon, Oct 24, 2011 at 10:29:57AM +0200, Jan Vornberger wrote:
Hi there!
As part of my green address endeavor, I'm currently trying to extend the
'gettransaction' call to include an extra field inputaddresses which
should return a list of the Bitcoin addresses associated with the inputs
of
So my first shot at this is to go through the inputs of a transaction and
see if the scriptSig field has only two opcodes. If that is the case, I
assume that it is of the structure sig pubKey and calculate the
Bitcoin address from pubKey.
But then I started to wonder if this is safe. Can this
Yes, you're right, there is a lot of code is in the fun with knives
category.
JS
On Mon, Oct 24, 2011 at 4:31 PM, Amir Taaki zgen...@yahoo.com wrote:
Hahaha you mean like unitialised variables, inheriting from containers with
non-virtual dtors (CScript) and delicious copy pasta coding
PKI would avoid the need for the trust aggregator to be consulted for
each transaction. Obviously checking for revocation would be essential.
The CA cert can state what kind of guarantee is available.
Simon
On 10/24/2011 09:25 AM, Mike Hearn wrote:
You know, just thinking out loud...
Those indeed seems weird... I'll take a look at it.
JS
On Mon, Oct 24, 2011 at 8:55 PM, Geir Harald Hansen
opera...@bitminter.comwrote:
Three quick examples of duplicated strings. There are many more. Some of
the smaller ones may make sense to have duplicated several times in
english as
Am Mo, 24.10.2011, 16:55, schrieb Gavin Andresen:
So my first shot at this is to go through the inputs of a transaction and
see if the scriptSig field has only two opcodes. If that is the case, I
assume that it is of the structure sig pubKey and calculate the
Bitcoin address from pubKey.
But
On Tue, 2011-10-25 at 11:45 +0200, Jan Vornberger wrote:
1) Get something working reasonable fast to detect current green address
style transactions. It's fine if it is a little bit of a hack, as long as
it's safe, since I don't expect it to be merged with mainline anyway at
this point.
2)
Interesting suggestion! So if I understand correctly, greensig would be
the signature generated from signing the transaction with the key of a
green address?
Sure. Or just a key. It wouldn't have to be an actual key used in
the block chain.
Sounds good - I guess I never thought in this
scriptPubKeys that use OP_EVAL contain a hash of a script. If I
understand correctly, that means to detect a transaction in a block
that is relevant to your wallet, that means you need to pre-calculate
every possible hash that might appear.
For the case of a single payment, that's not a problem.
On Tue, Oct 25, 2011 at 6:49 AM, Mike Hearn m...@plan99.net wrote:
scriptPubKeys that use OP_EVAL contain a hash of a script. If I
understand correctly, that means to detect a transaction in a block
that is relevant to your wallet, that means you need to pre-calculate
every possible hash that
On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen gavinandre...@gmail.com wrote:
You give the hash to whoever is paying you, and store the hash --
script mapping when you do that (assuming you're not using a
deterministic wallet; if you are, you probably just increment a
counter in the wallet).
I think it is a very important feature to be able to extract transaction
to/from you only from your private keys. In the standard transactions this is
easily accomplished - in the case you only want to find the addr to tx mapping:
vectorpairopcodetype, vectorunsigned char vSolution;
if
On Wed, Oct 26, 2011 at 4:58 AM, Michael Grønager grona...@ceptacle.com wrote:
I think it is a very important feature to be able to extract transaction
to/from you only from your private keys. In the standard transactions this is
easily accomplished - in the case you only want to find the
OK, let me try to explain what I see is the problem:
So far we the bitcoin addresses are (for all practical purposes) a one-to-one
mapping between a pubkey and uint160. This mean that your wallet is defined
solely by your privatekeys (from which you can extract pubkeys and then uint160
Anybody know how to contact MT about getting it back online? I still haven't
finished copy-editing the BIPs and need access to them since there's a new one
to be added.
--
The demand for IT networking professionals
I just posted BIP 0010 to gist : https://gist.github.com/1321518
The goal is to provide a standard method for proposing how to spend
multi-sig TxOuts, and collect signatures without actually having to
understand BTC under-the-hood. I envision, even without any program
installed,
RE: buying me and Gregory a shared beer:
I would make a both of two btc-addresses script transaction using OP_EVAL.
And post it.
You would then not be able to know that you actually got a beer unless I told
you so in a mail.
But that transaction won't show up in my bitcoin wallet as
Hey,
Can we lock the version numbers to be the protocol version (which changes
rarely) and instead use the sub_version_num field + revision number for
individual builds?
Satoshi 0.4
BitcoinJava 120311
bitcoin-js 6
Like so. Otherwise we will have version bumping insanity :)
I don't really get what you want to achieve with this. The protocol will be
slow down evolution (hopefully) soon, while the clients will continue
releasing at a similar rhythm. It took long enough to decouple the protocol
version from being bumped each client release, now doing the inverse
Point taken.
About the sub_version_num though. I prefer to let the field by defined clients
however they wish, with just a guideline suggestion that IDENTIFIER VERSION is
a format they should follow.
The idea being that different projects would have different release scheduling
schemes and
Just for reference: https://github.com/bitcoin/bitcoin/pull/63
The issue resulted in my most useless pull request fixing two variables :-)
I second the use of sub_version_num as a Client and Version identifier.
Regards,
Chris
On Wed, Nov 2, 2011 at 11:33 PM, Amir Taaki zgen...@yahoo.com wrote:
On Wednesday, November 02, 2011 6:33:12 PM Amir Taaki wrote:
Satoshi 0.5
What is Satoshi 0.5 anyway? 0.5's server is bitcoind and GUI is Bitcoin-Qt;
the wx GUI client is gone, which is more or less what Satoshi referred to in
the past...
Bitcoin is the protocol. The client protocol identifier needs a unique name. It
is not a public name that anybody ever sees except protocol developers.
For instance with libbitcoin, there might be several clients using it, but
they'd all have the same protocol identifier.
I think calling it
What's wrong with the mac build? I just built on 10.7 without any issues.
--
Douglas Huff
On Nov 4, 2011, at 4:29 PM, Gavin Andresen wrote:
If you wonder where the bitcoin-0.5.0rc2-linux.tar.gz went...
I removed it because it is not sane (we need to teach the Qt build to
statically link
BitCoinJ already sets the subver field to its name and version.
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1___
On BitDroid I stopped updating the protocol version at 31700 and set the
string to be both Version and Client, just like BitcoinJ :-)
On Sat, Nov 5, 2011 at 3:32 PM, Mike Hearn m...@plan99.net wrote:
BitCoinJ already sets the subver field to its name and version.
From talking with Patrick Strateman (phantomcircuit), he suggested this idea
(which I will elaborate more on in the BIP):
User-agent strings are a good starting point, however they aren't easy for
parsing so we'll make a small modification to them.
We need a hierarchy from protocol, variant,
Sorry for shooting this approach down, but I'm against it. User-agent
strings are an extremely bad idea as it would lead developers to start
making communication choices depending on the client type. User-Agents in
HTTP are only useful if the clients (browsers) do not adhere to a well
defined
On Saturday, November 05, 2011 12:17:58 PM Christian Decker wrote:
Sorry for shooting this approach down, but I'm against it. User-agent
strings are an extremely bad idea as it would lead developers to start
making communication choices depending on the client type.
This can be necessary in
If clients break the network protocol/do not comply properly with it,
they should be disconnected and shunned. Hard love. We don't want any
ambiguity in the protocol.
However my feeling about the user-agent string is that it is a vanity
item, but here we'd be enforcing a format that
On Tue, Sep 13, 2011 at 11:06:37AM -0400, Gavin Andresen wrote:
Background:
Timejacking:
http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html
And a recent related exploit launched against the low-difficulty
alternative chains:
On Monday, November 07, 2011 10:02:43 AM Pieter Wuille wrote:
Maybe a short interval (1 minute? 10 minutes?) instead of a fixed
value could be allowed for the multiple-of-2016 blocks.
Reminder that there is *already* a short interval only allowed for blocks in
general...
On Mon, Nov 07, 2011 at 10:27:57AM -0500, Luke-Jr wrote:
On Monday, November 07, 2011 10:02:43 AM Pieter Wuille wrote:
Maybe a short interval (1 minute? 10 minutes?) instead of a fixed
value could be allowed for the multiple-of-2016 blocks.
Reminder that there is *already* a short interval
Hi All,
Along with the multisig/op_eval BIPs (11/12) I am considering how the actual
client functionality could be.
Some of you might already have the solution for this - if not I would like to
propose the following...
Lets consider the 2 of 3 multisig - and lets say I now have some coins
That's what my proposal was for, in BIP 0010:
https://github.com/genjix/bips/blob/master/bip-0010.md
However, I just found a minor problem with it that should be addressed
if we want to enable super-lightweight clients that only sign tx's
without needing the blockchain. Simply that the TxIns
Actually, I'm not sure if your solution works, because it relies on
broadcasting a tx to the network that isn't valid. I believe that the
first tx in your proposal will be rejected and thus you'll need to exchange
the tx's offline.
However, third-parties could pretty easily and conveniently
I don't think partially-signed transactions belong on the main Bitcoin
P2P network, mostly because I don't see any way of preventing somebody
from endlessly spamming bogus, will-never-be-completed partial
transactions just to be annoying.
... of course I write that and then start thinking
Crossing posts ;)
I like your idea! - It adds a pricetag to distributing a signature - and - as
you mention it will be part of the standard. It is only up to the clients if
they want to support it or not, but it does give you 0-conf world wide
instantaneous anonymously distribution of
One more thought on putting arbitrary stuff in the scriptSig:
Miners could decide to revolt and remove the extra scriptSig
information before including the transaction in their blocks. They'd
still get the full transaction fee, and the transaction would still
validate so the block would be
It's propably best to create a separate p2p network for off-band
information like this. No need to involve the blockchain with it.
- Joel
On Wed, 2011-11-09 at 16:18 -0500, Gavin Andresen wrote:
One more thought on putting arbitrary stuff in the scriptSig:
Miners could decide to revolt and
1 - 100 of 6192 matches
Mail list logo
