On Tue, Jun 17, 2014 at 11:29 PM, Jeff Garzik wrote:
> I wrote a patch for string-based name extensions, circa 2011-2012. I
> agree that is preferable to unreadable bits, for reasons you cite.
>
> However, it was noted that extensions (or UUIDs etc.) would not be
> propagated around the network i
On 6/16/2014 8:48 AM, Mike Hearn wrote:
> In practice of course this is something payment processors like Bitpay
> and Coinbase will think about. Individual cafes etc who are just using
> mobile wallets won't be able to deal with this complexity: if we can't
> make native Bitcoin work well enoug
On 6/16/2014 8:09 AM, Daniel Rice wrote:
> What if we solved doublespends like this: If a node receives 2
> transactions that use the same input, they can put both of them into
> the new block as a proof of double spend, but the bitcoins are not
> sent to the outputs of either transactions. They
On Tue, Jun 17, 2014 at 03:40:36PM -0400, Gavin Andresen wrote:
> Assuming there is rough consensus, I'll make this a pull request (see
> https://github.com/gavinandresen/bitcoin-git/tree/relax_isstandard for code
> changes).
I'm also working on a very similar patch with some additional
protection
On 06/17/2014 06:46 PM, Gregory Maxwell wrote:
> The correct place for more information is the Bitcointalk forum thread
> where it was announced:
> https://bitcointalk.org/index.php?topic=279249.0
Can anyone summarize the current status of the bounty? I see nothing
definite about the bounty in tha
On Tue, Jun 17, 2014 at 2:14 PM, Odinn Cyberguerrilla
wrote:
> Hoping that this is the right place for this, I am asking a question as to
> what happens with what is in the CoinJoin bounty fund address at:
The correct place for more information is the Bitcointalk forum thread
where it was announc
Not with current script, but there are mechanisms by which you can do a
digital signature where signing two pieces of information reveals the
ECDSA k parameter, thereby allowing anyone to recover the private key
and steal the coins.
Practically speaking, these are not very safe systems to use. For
I wrote a patch for string-based name extensions, circa 2011-2012. I
agree that is preferable to unreadable bits, for reasons you cite.
However, it was noted that extensions (or UUIDs etc.) would not be
propagated around the network in "addr" messages, as service bits are.
On Tue, Jun 17, 2014 a
Hoping that this is the right place for this, I am asking a question as to
what happens with what is in the CoinJoin bounty fund address at:
http://blockchain.info/address/3M8XGFBKwkf7miBzpkU3x2DoWwAVrD1mhk
(a P2SH / multisignature address)
I encouraged people to donate to it in late 2013 (aroun
Can two signed transactions using the same output as an input (ie, a double
spend) be used to trigger a third transaction?
It would be nice if I could sign a tx that would pay m bitcoins to an arbitrary
address if and only if someone could present proof that I signed more than 1
transaction us
Assuming there is rough consensus, I'll make this a pull request (see
https://github.com/gavinandresen/bitcoin-git/tree/relax_isstandard for code
changes).
Now that we are finally starting to see the use of multi-signature and
other more complicated transaction forms in applications I think
But miners dont want to run full nodes, its better to develop some SPV like
that connects to some nodes.
Also I believe that stratum mining protocol improves some performance
things that GBT lacks.
If a new protocol that requires blocks created by miners is developed and
named in a cool way, mine
On Tue, Jun 17, 2014 at 4:20 PM, Christophe Biocca
wrote:
> https://en.bitcoin.it/wiki/Getblocktemplate is supposed to solve most
> of the pooling-centralization problems.
This. There is no need to create anything new when GBT already exists.
In my opinion.
> Unfortunately, it is opt-in,
> and G
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/16/2014 07:00 PM, Justus Ranvier wrote:
>> There can be multiple independent transport networks for Bitcoin.
>>
>> There already is: ipv4, ipv6, Tor, and native_i2p (out of tree
>> patch).
>>
>> As long as multihomed hosts that act as brid
quote:
> Mike Hearn, why don't we just have all nodes report attempted double spends
> through the node network. No need to involve the miners at all really, or
> do your suggestion but also report the double spend attempt. By waiting
> maybe 10-60 seconds (instead of 10 minutes for first conf), me
quote:
> On 6/16/14, Mike Hearn wrote:
> > If they decide to change to something like highest-fee-always-wins, then
> > they (again) centralise things by forcing all instant transactions to pay
> > GreenAddress and its competitors money - much though I like your product
> > Lawrence, let's hope th
quote:
> https://en.bitcoin.it/wiki/Getblocktemplate is supposed to solve most
> of the pooling-centralization problems. Unfortunately, it is opt-in,
> and GHash.io doesn't support it.
>
> Also most miners don't care and don't do the work to set it up. To do
> transaction inclusion themselves, the
On Tue, Jun 17, 2014 at 4:27 PM, Jesus Cea wrote:
> On 17/06/14 11:46, Wladimir wrote:
> Under Ubuntu 10.04:
>
> jcea@ubuntu:/tmp/bitcoin-0.9.2-linux/bin/64$ ./bitcoin-qt
> ./bitcoin-qt: symbol lookup error: ./bitcoin-qt: undefined symbol:
> _ZN10QTextCodec11validCodecsEv
Did it work with the rel
On 17/06/14 11:46, Wladimir wrote:
> For Linux we now build against Qt 4.6, and filter the symbols for
> libstdc++ and glibc.
> This brings back compatibility with
>
> - Debian 6+ / Tails
> - Ubuntu 10.04
> - CentOS 6.5
Under Ubuntu 10.04:
jcea@ubuntu:/tmp/bitcoin-0.9.2-linux/bin/64$ ./bitcoin-q
https://en.bitcoin.it/wiki/Getblocktemplate is supposed to solve most
of the pooling-centralization problems. Unfortunately, it is opt-in,
and GHash.io doesn't support it.
Also most miners don't care and don't do the work to set it up. To do
transaction inclusion themselves, they'd need to run a f
as I understood your proposal the entire block would be created on the
miner rather than just the block header. Currently miners do not receive a
list of transactions, they receive information required to create the block
header, this is how you keep miners honest. if the miner is creating the
full
Because he cant change the coinbase once the proof of work is done.
El 17/06/2014 15:58, "Ron Elliott" escribió:
> In this scenario how do you ensure the miner solving the block cannot
> reapportion the subsidy to himself rather than the pool?
> On Jun 17, 2014 2:09 AM, "Raúl Martínez" wrote:
>
In this scenario how do you ensure the miner solving the block cannot
reapportion the subsidy to himself rather than the pool?
On Jun 17, 2014 2:09 AM, "Raúl Martínez" wrote:
> First of all I apologice due to the possible mistakes in my writing below,
> I am not a Bitcoin developer but I have som
Bitcoin Core version 0.9.2 is now available from:
https://bitcoin.org/bin/0.9.2/
(or https://bitcoin.org/en/download)
This is a new minor version release, bringing mostly bug fixes and some minor
improvements. OpenSSL has been updated because of a security issue
(CVE-2014-0224).
Upgrading to t
I have been surprised by the lack of discussion of this topic here!
On 6/17/2014 10:57 AM, Raúl Martínez wrote:
We all know the recent news, Ghash pool controlling 51% of the hashrate.
While some consider it a threat others think that is not harmful.
The thing is that we have to do something to
First of all I apologice due to the possible mistakes in my writing below,
I am not a Bitcoin developer but I have some knowledge about it.
We all know the recent news, Ghash pool controlling 51% of the hashrate.
While some consider it a threat others think that is not harmful.
The thing is
On Tue, Jun 17, 2014 at 10:08 AM, Wladimir wrote:
> On Tue, Jun 17, 2014 at 10:02 AM, Matt Whitlock
> wrote:
>> On Tuesday, 17 June 2014, at 9:57 am, Wladimir wrote:
>>> Yes, as I said in the github topic
>>> (https://github.com/bitcoin/bitcoin/pull/4351) I suggest we adapt a
>>> string-based na
On Tue, Jun 17, 2014 at 10:02 AM, Matt Whitlock wrote:
> On Tuesday, 17 June 2014, at 9:57 am, Wladimir wrote:
>> Yes, as I said in the github topic
>> (https://github.com/bitcoin/bitcoin/pull/4351) I suggest we adapt a
>> string-based name space for extensions.
>
> Why use textual strings? These
On Tuesday, 17 June 2014, at 9:57 am, Wladimir wrote:
> Yes, as I said in the github topic
> (https://github.com/bitcoin/bitcoin/pull/4351) I suggest we adapt a
> string-based name space for extensions.
Why use textual strings? These fields are not for human consumption. Why not
use UUIDs, which
On Tue, Jun 17, 2014 at 9:23 AM, Peter Todd wrote:
> Alternately Wladimir J. van der Laan brought up elsewhere(2) the
> possibility for a wider notion of an extension namespace. I'm personally
> not convinced of the short-term need - we've got 64 service bits yet
> NODE_BLOOM is the first fully f
For my replace-by-fee implementation(1) I used service bit 26 to let
preferential peering work so that replace-by-fee nodes could easily find
each other. Of course, that's a temporary/experimental usage that can be
dropped after wider adoption, so I included the following comment:
// Reserve 2
31 matches
Mail list logo
