On Tue, Jun 17, 2014 at 10:08 AM, Wladimir laa...@gmail.com wrote:
On Tue, Jun 17, 2014 at 10:02 AM, Matt Whitlock b...@mattwhitlock.name
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
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
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
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
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 r...@i-rme.es wrote:
First of all I apologice due to the possible mistakes in my writing below,
I am not a Bitcoin developer but
Because he cant change the coinbase once the proof of work is done.
El 17/06/2014 15:58, Ron Elliott ronaldbelli...@gmail.com 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
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
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-qt
On Tue, Jun 17, 2014 at 4:27 PM, Jesus Cea j...@jcea.es 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
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, they'd
quote:
On 6/16/14, Mike Hearn m...@plan99.net 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
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),
On Tue, Jun 17, 2014 at 4:20 PM, Christophe Biocca
christophe.bio...@gmail.com 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.
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,
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
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
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
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 at
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.
On Tue, Jun 17, 2014 at 2:14 PM, Odinn Cyberguerrilla
odinn.cyberguerri...@riseup.net 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
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 that
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 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 enough
23 matches
Mail list logo
