On Thu, Aug 22, 2013 at 11:26 PM, Maciej Trebacz mac...@bitalo.com wrote:
So if you have multiple addresses you can't
sign them with a single private key and include that signature in the
transaction so other party can verify it against your public key. This could
become very handy though - a
Please return your seats and fasten your seat-belts.
All Bitcoin-qt / Bitcoind nodes will currently fail to come back up
after a restart, reporting
: *** coin database inconsistencies found
and
Do you want to rebuild the block database now?
Reindexing _will not_ correct the problem. In
On Mon, Sep 9, 2013 at 1:53 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
More information will be forthcoming once a patch is available.
I now have a patch up for review.
https://github.com/bitcoin/bitcoin/pull/2982
(You should wait until other developers have had a chance to review
before
On Tue, Sep 10, 2013 at 2:03 PM, Matthew Mitchell
matthewmitch...@godofgod.co.uk wrote:
Well let's hope something like murder black people, stupid asian person
or whip african slave doesn't come up. :-) Maybe it would have been better
without the aggressive words?
Ouch.
This sounds like
On Tue, Sep 17, 2013 at 4:00 AM, Mike Hearn m...@plan99.net wrote:
LevelDB is fast - very fast if you give it enough CPU time and disk seeks.
But it's not the last word in performance.
I'd looked at the hyperleveldb, but their performance graphs made it
seem like it would be slower for the
On Sat, Oct 19, 2013 at 3:29 PM, Luke-Jr l...@dashjr.org wrote:
See BIP 1 for the process.. proposals go to this mailing list first.
FWIW, he did post to the mailing list and he got an underwhelming response:
On Mon, Oct 21, 2013 at 11:59 PM, Jean-Paul Kogelman
jeanpaulkogel...@me.com wrote:
Have you seen: https://en.bitcoin.it/wiki/Protocol_specification ?
Take care, the information in the wiki is woefully incomplete.
--
On Tue, Oct 22, 2013 at 12:34 AM, Martin Sustrik sust...@250bpm.com wrote:
There's also Security Considerations part in
every RFC that is pretty relevant for Bitcoin.
Which would say something interesting like If the bitcoin network
implements inconsistent behavior in the consensus critical
On Fri, Oct 25, 2013 at 11:50 AM, Mike Caldwell
mcaldw...@swipeclock.com wrote:
I have noticed that there was a recent change to BIP 0038
(Password-Protected Private Key) on the Wiki, which is a proposal I wrote in
late 2012. Gregory, it looks to me as though you have made this change, and
One limitation of the payment protocol as speced is that there is no
way for a hidden service site to make use of its full authentication
capability because they are unable to get SSL certificates issued to
them.
A tor hidden service (onion site) is controlled by an RSA key.
It would be trivial
On Fri, Oct 25, 2013 at 8:41 PM, Luke-Jr l...@dashjr.org wrote:
Is there any point to additional encryption over tor (which afaik is already
encrypted end-to-end)? Is there a safe way to make this work through tor entry
nodes/gateways?
The x.509 in the payment protocol itself is for
On Mon, Oct 28, 2013 at 2:26 AM, Andreas Schildbach
andr...@schildbach.de wrote:
HTTP also defines success codes (2xx). Are we also talking about ACK
messages now, rather than just REJECT messages?
I do not believe we should do that: It would be a non-trivial
increase the protocol bandwidth
On Sun, Oct 27, 2013 at 7:32 AM, Mike Hearn m...@plan99.net wrote:
I'm really looking forward to this. Currently bitcoinj gets a small but
steady stream of bug reports of the form my transaction did not propagate.
It's flaky because the library picks one peer to send the transaction to,
and
On Mon, Nov 4, 2013 at 3:58 AM, Michael Gronager grona...@ceptacle.com wrote:
The suggested change is actually very simple (minutes of coding) and
elegant and addresses precisely the identified problem. It is actually a
mental shortcut in the assumption of how probability works when mining a
On Mon, Nov 4, 2013 at 8:39 PM, Peter Todd p...@petertodd.org wrote:
I suggested the mechanism myself for slightly different reasons, and if
you know me, you'd know I'm the first to jump on anyone pushing
centralization.
Likewise, I did too and am also not very tolerant with trusted or
On Tue, Nov 5, 2013 at 2:15 PM, Drak d...@zikula.org wrote:
If I understand the issue properly, this seems like a pretty elegant
solution: if two blocks are broadcast within a certain period of eachother,
chose the lower target. That's a provable fair way of randomly choosing the
winning block
On Fri, Nov 8, 2013 at 11:49 AM, Andreas M. Antonopoulos
andr...@rooteleven.com wrote:
Nicholas Weaver is reporting that pools have already started delaying
blocks, something that hints at Selfish Mining, since Nov. 3rd.
https://medium.com/something-like-falling/d321a2ef9317
He dismisses
On Tue, Nov 19, 2013 at 8:53 AM, Drak d...@zikula.org wrote:
It's quite normal for standards bodies to allocate numbers when in draft
status. If they don't pass, they don't pass - they are clearly labelled
DRAFTs.
+1 on having things in a github repository. Much better for collaboration,
The
On Fri, Nov 22, 2013 at 12:49 PM, Jeff Garzik jgar...@bitpay.com wrote:
Whitelist nodes against banning.
Is there a reason not to have a parallel get rpc to get the current list?
--
Shape the Mobile Experience: Free
On Sun, Dec 8, 2013 at 11:16 AM, Drak d...@zikula.org wrote:
BGP redirection is a reality and can be exploited without much
You're managing to argue against SSL. Because it actually provides
basically protection against an attacker who can actively intercept
traffic to the server. Against that
On Sun, Dec 8, 2013 at 12:40 PM, Drak d...@zikula.org wrote:
Let me clarify. SSL renders BGP redirection useless because the browser
holds the signatures of CA's it trusts: an attacker cannot spoof a
certificate because it needs to be signed by a trusted CA: that's the point
of SSL, it
On Mon, Dec 9, 2013 at 7:19 AM, Drak d...@zikula.org wrote:
Why would it be made available for download at sourceforge.net if it's not
actually released? The files are available here:
Because it takes time to put the files up, propagate to mirrors, check
by multiple people that the downloads
On Tue, Dec 17, 2013 at 2:41 PM, Troy Benjegerdes ho...@hozed.org wrote:
I want to get some feedback.. I've used distributed version control
systems for a long time, and the most useful feature is to be able
to merge two different forks.
We already automatically merge forks that we become
On Thu, Dec 19, 2013 at 5:47 PM, Mark Friedenbach m...@monetize.io wrote:
Hello fellow bitcoin developers. Included below is the first draft of
a BIP for a new Merkle-compressed data structure. The need for this
data structure arose out of the misnamed Ultimate blockchain
compression project,
On Tue, Dec 31, 2013 at 5:39 AM, Drak d...@zikula.org wrote:
The NSA has the ability, right now to change every download of bitcoin-qt,
on the fly and the only cure is encryption.
Please cut it out with the snake oil pedaling. This is really over the
top. You're invoking the NSA as the threat
On Thu, Jan 2, 2014 at 9:22 PM, Troy Benjegerdes ho...@hozed.org wrote:
I believe this is self-explainatory:
1) Bitcoin usually runs on port 8333. Why?
2) Bitcoin does not show in up
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
.. why?
3)
On Fri, Jan 3, 2014 at 10:00 AM, Nadav Ivgi na...@shesek.info wrote:
I had an idea for a payment scheme that uses key derivation, but instead of
the payee deriving the addresses, the payer would do it.
It would work like that:
The payee publishes his master public key
The payer generates a
On Mon, Jan 13, 2014 at 11:59 AM, Alan Reiner etothe...@gmail.com wrote:
Then when someone
wants to pay you, you simply give them the multiplier and root key (they
already have the root key, but should verify).
[...]
What
advantages does stealth addresses have over this scheme? You could
On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport bendavenp...@gmail.com wrote:
But may I suggest we consider changing the name stealth address to
something more neutral?
ACK. Regardless of the 'political' overtones, I think stealth is a
little cringe-worthy.
Private address would be fine if
On Wed, Jan 15, 2014 at 4:05 PM, Jeremy Spilman jer...@taplink.co wrote:
Might I propose reusable address.
I like this too.
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are
One challenge with reusable addresses is that while they result in a
small constant overhead for full nodes in searching for their own
transactions they create large overheads for SPV nodes.
One way to address this is for the SPV nodes to hand their servers
their blinding private key so that the
On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner etothe...@gmail.com wrote:
Isn't there a much faster asymmetric scheme that we can use? I've heard
people talk about ed25519, though I'm not sure it can be used for encryption.
Doing ECDH with our curve is within a factor of ~2 of the fastest
On Sat, Jan 18, 2014 at 3:12 PM, Jeremy Spilman jer...@taplink.co wrote:
In the case where payment is being sent only to Q1, and Q2 is for discovery
only, perhaps we could use a 160-bit curve for d2/Q2 and e/P resulting in 20
byte vs 32 bytes in the OP_RETURN, and of course faster
On Mon, Feb 10, 2014 at 3:28 AM, Drak d...@zikula.org wrote:
What is the official response from the Bitcoin Core developers about MtGox's
assertion that their problems are due to a fault of bitcoin, as opposed to a
fault of their own?
The technical analysis preluding this mess, was that MtGox
On Mon, Feb 10, 2014 at 8:30 AM, Troy Benjegerdes ho...@hozed.org wrote:
Name me one single person with commit access to the bitcoin github repository
who is *independent* of any venture capital or other 'investment' connections.
I am, unless you count the fact that I own some Bitcoin and some
On Mon, Feb 10, 2014 at 11:47 AM, Oliver Egginger bitc...@olivere.de wrote:
As I understand this attack someone renames the transaction ID before
being confirmed in the blockchain. Not easy but if he is fast enough it
should be possible. With a bit of luck for the attacker the new
transaction
On Mon, Feb 10, 2014 at 12:47 PM, Tier Nolan tier.no...@gmail.com wrote:
If the attacker has a direct connection to MtGox, they can receive the
transaction directly.
MtGox had a php script that returned base64 data for all their stalled
transactions.
Not just attackers used that, some people
On Tue, Feb 11, 2014 at 12:42 PM, naman naman nama...@gmail.com wrote:
I was talking about a DOS attack in
https://bitcointalk.org/index.php?topic=458608.0 (ofcourse only applicable
to entitys doing the tracking with txids).
Amazing how I did not get a response from any of the devs (except
On Wed, Feb 12, 2014 at 7:12 AM, Rune Kjær Svendsen runesv...@gmail.com wrote:
Instead of trying to remove the possibility of transaction
malleability, would it make sense to define a new, canonical
transaction hash/ID (cTxID), which would be a hash of the part of the
transaction data which we
On Wed, Feb 12, 2014 at 4:39 PM, Alex Morcos mor...@gmail.com wrote:
I apologize if this has been discussed many times before.
It has been, but there are probably many people like you who have not
bothered researching who may also be curious.
As a long term solution to malleable transactions,
On Wed, Feb 19, 2014 at 12:28 PM, Michael Gronager grona...@mac.com wrote:
Twisting your words a bit I read:
* you want to support relay of transactions that can be changed on the fly,
but you consider it wrong to modify them.
* #3 is already not forwarded, but you still find it relevant to
dOn Wed, Feb 19, 2014 at 12:49 PM, Peter Todd p...@petertodd.org wrote:
While we might be able to get away with a retroactive change in meaning right
now in the future that won't be so easy. There are lots if proposed
applications for nLockTime-using protocols that depend on transactions (or
On Thu, Feb 20, 2014 at 6:08 AM, Mike Hearn m...@plan99.net wrote:
We've done forking changes before much faster than a year and that was with
less experience. If we want, we can get this done within months.
You mean P2SH... which your implementation has only picked up support
for in the last
On Thu, Feb 20, 2014 at 6:29 AM, Gavin Andresen gavinandre...@gmail.com wrote:
I think we should get Pieter's proposal done and implemented quickly. I
agree with Mike, it doesn't have to take a long time for the core network to
fully support this.
Getting wallets to start generating
On Thu, Feb 20, 2014 at 7:11 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
I hereby request a BIP number.
62 assigned.
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to
On Thu, Feb 20, 2014 at 10:07 PM, Mike Hearn m...@plan99.net wrote:
No, I was thinking of the height in coinbase change. At any rate, p2sh was
supported by the consensus code in bitcoinj for a long time already, since
it was first written.
Support for sending to such addresses in the wallet
On Mon, Feb 24, 2014 at 3:06 PM, Andreas Petersson andr...@petersson.at wrote:
Regarding 80 bytes vs smaller: The objectives should be that if you are
determined to put some extra data in the blockchain, OP_RETURN should be
the superior alternative. if a user can include more data with less
On Wed, Mar 5, 2014 at 12:32 PM, Peter Todd p...@petertodd.org wrote:
That's nice, but I wrote my advice to show people how even if they don't
know any crypto beyond what the black boxes do - the absolute minimum
you need to know to write any Bitcoin software - you can still defend
yourself
On Wed, Mar 5, 2014 at 1:31 PM, Eric Lombrozo elombr...@gmail.com wrote:
If we don't mind sacrificing some performance when signing, there's a fairly
simple way to implement a constant-time constant-cache-access-pattern
secp256k1.
It is based on the idea of branchless implementations of the
On Wed, Mar 5, 2014 at 2:14 PM, Eric Lombrozo elombr...@gmail.com wrote:
Everything you say is true.
However, branchless does reduce the attack surface considerably - if nothing
else, it significantly ups the difficulty of an attack for a relatively low
cost in program complexity, and that
On Wed, Mar 5, 2014 at 2:17 PM, Kevin kevinsisco61...@gmail.com wrote:
Hello. How would I submit a patch? Could it be sent through the list
as an attachment?
To the reference software? Normally you'd open a github account and
submit there.
Though if for some reason you can't— though its
On Sat, Mar 8, 2014 at 11:34 AM, Luke-Jr l...@dashjr.org wrote:
On Wednesday, March 05, 2014 4:21:52 PM Kevin wrote:
How can we patch this issue?
No need, it is not an issue for Bitcoin.
Properly used, there is only ever one signature per public key.
Security shouldn't depend on perfect use.
On Sun, Mar 16, 2014 at 6:24 AM, Thomas Voegtlin thoma...@gmx.de wrote:
The encryption algorithm is ECIES, and code was was borrowed from
https://github.com/jackjack-jj/jeeq. In order to know the public
key corresponding to a Bitcoin address in your wallet, you can use
the
On Sun, Mar 16, 2014 at 7:31 AM, Thomas Voegtlin thoma...@gmx.de wrote:
thanks for your feedback!
I was not aware that that implementation was flawed.
I will see how I can fix that code and get back to you.
It also leaks on the order of 7 bits of data about the message per
message chunk. I'm
On Sun, Mar 16, 2014 at 3:58 PM, Adam Back a...@cypherspace.org wrote:
2. you move coins to the side-chain by spending them to a fancy script,
which suspends them, and allows them to be reanimated by the production of
an SPV proof of burn on the side-chain.
One point to note here is that the
On Tue, Mar 25, 2014 at 2:03 PM, Mark Friedenbach m...@monetize.io wrote:
More importantly, to your last point there is absolutely no way this
scheme can lead to inflation. The worst that could happen is theft of
coins willingly put into the pegging pool. But in no way is it possible
to
On Sat, Mar 29, 2014 at 10:38 AM, Matt Whitlock b...@mattwhitlock.name wrote:
But can threshold ECDSA work with BIP32?
Yes.
In other words, can a threshold ECDSA public key be generated from separate,
precomputed private keys,
No.
can it only be generated interactively?
Yes.
But see the
On Sat, Mar 29, 2014 at 12:59 PM, Justus Ranvier
justusranv...@gmail.com wrote:
What would make it easier is if there was a standard output type for
sending the entire transaction to miner fees,
Hm. maybe it could be called a return operator or something like that? :)
that would make even
On Sat, Mar 29, 2014 at 1:20 PM, Justus Ranvier justusranv...@gmail.com wrote:
On 03/29/2014 08:05 PM, Gregory Maxwell wrote:
Use dust-b-gone and make it someone elses problem to get it relayed. :)
That's a sub-optimal solution, as it introduces a third party. What if
his server goes down
On Tue, Apr 1, 2014 at 12:00 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
Hi all,
I understand this is a controversial proposal, but bear with me please.
I believe we cannot accept the current subsidy schedule anymore, so I
wrote a small draft BIP with a proposal to turn Bitcoin into a
On Tue, Apr 1, 2014 at 1:53 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
In case there are no further objections (excluding from people who
disagree with me), I'd like to request a BIP number for this. Any
number is fine, I guess, as long as it's finite.
With ten people commenting on this
On Fri, Apr 4, 2014 at 6:51 AM, Nikita Schmidt
nik...@megiontechnologies.com wrote:
Fair enough. Although I would have chosen the field order (p) simply
because that's how all arithmetic already works in bitcoin. One field
for everybody. It's also very close to 2^256, although still smaller
On Fri, Apr 4, 2014 at 9:36 AM, Matt Whitlock b...@mattwhitlock.name wrote:
Are you proposing to switch from prime fields to a binary field? Because if
you're going to break up a secret into little pieces, you can't assume that
every piece of the secret will be strictly less than some 8-bit
On Fri, Apr 4, 2014 at 10:16 AM, Matt Whitlock b...@mattwhitlock.name wrote:
Honestly, that sounds a lot more complicated than what I have now. I made my
current implementation because I just wanted something simple that would let
me divide a private key into shares for purposes of
On Thu, Apr 3, 2014 at 8:41 PM, kjj bitcoin-de...@jerviss.org wrote:
At first, I thought this was a second April Fool's joke, but then I
looked and saw that all of the BIPs really do use this format. As far
as I can tell, we are using this insane format because RFC 822 predates
ISO 8601 by
On Mon, Apr 7, 2014 at 4:34 AM, Mike Hearn m...@plan99.net 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
On Mon, Apr 7, 2014 at 6:50 AM, Gregory Maxwell gmaxw...@gmail.com 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
On Mon, Apr 7, 2014 at 6:58 AM, Jameson Lopp jameson.l...@gmail.com 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.
On Mon, Apr 7, 2014 at 9:27 AM, Mark Friedenbach m...@monetize.io 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
On Mon, Apr 7, 2014 at 10:01 AM, Mark Friedenbach m...@monetize.io 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
On Mon, Apr 7, 2014 at 10:40 AM, Mike Hearn m...@plan99.net 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
On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer ta...@bitsofproof.com 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
On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer ta...@bitsofproof.com 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,
On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer ta...@bitsofproof.com 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
On Mon, Apr 7, 2014 at 2:48 PM, Tier Nolan tier.no...@gmail.com 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
On Mon, Apr 7, 2014 at 5:33 PM, Nikita Schmidt
nik...@megiontechnologies.com 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.
On Mon, Apr 7, 2014 at 6:46 PM, Matt Whitlock b...@mattwhitlock.name wrote:
On Monday, 7 April 2014, at 5:38 pm, Gregory Maxwell wrote:
On Mon, Apr 7, 2014 at 5:33 PM, Nikita Schmidt
nik...@megiontechnologies.com wrote:
Regarding the choice of fields, any implementation of this BIP
On Tue, Apr 8, 2014 at 9:13 AM, Angel Leon gubat...@gmail.com wrote:
a home router that crashes or slows down when its NAT pin-hole table
overflows, triggered by many TCP connections.
We don't form or need to form a great many connections.
a home router that crashes or slows down by UDP
On Wed, Apr 9, 2014 at 8:42 AM, Brian Hoffman brianchoff...@gmail.com wrote:
How would this affect the user in terms of disk storage? They're going to
get hammered on space constraints aren't they? If it's not required how
likely are users to enable this?
If Bitcoin core activates pruning a
On Wed, Apr 9, 2014 at 8:41 AM, Natanael natanae...@gmail.com wrote:
This could probably be done fairly easily by bundling Stratum (it's
not just for pools!) and allowing SPV wallets to ask Bitcoind to start
it (if you don't use it, there's no need to waste the resources), and
then connect to
On Wed, Apr 9, 2014 at 11:35 AM, Justus Ranvier justusranv...@gmail.com wrote:
If the security of the network depends on a broken incentive model,
then fix the design of the network so that economics works for you
instead of against you.
Who says anything about a broken incentive model. You've
On Wed, Apr 9, 2014 at 1:36 PM, Mark Friedenbach m...@monetize.io wrote:
(2) there's a reasonable pathway to doing this all in-protocol, so there's
no reason to introduce external dependencies.
Not just a speculative pathway. Pieter implemented headers first:
On Thu, Apr 10, 2014 at 4:32 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
There were earlier discussions.
On this list.
The two ideas were either using one or a few service bits to indicate
availability of blocks, or to extend addr messages with some flags to
indicate this information.
On Thu, Apr 10, 2014 at 4:57 AM, Wladimir laa...@gmail.com wrote:
Just wondering: Would there be a use for a [static] node that, say, always
serves only the first 10 blocks? Or, even, a static range like block
10 - 20?
The last time we discussed this sipa collected data based on
On Thu, Apr 10, 2014 at 3:24 PM, Jesus Cea j...@jcea.es wrote:
On 11/04/14 00:15, Mark Friedenbach wrote:
Checkpoints will go away, eventually.
Why?. The points in the forum thread seem pretty sensible.
Because with headers first synchronization the major problems that
they solve— e.g. block
On Thu, Apr 10, 2014 at 10:30 AM, Tier Nolan tier.no...@gmail.com wrote:
Error correction is an interesting suggestion.
Though I mentioned it, it was in jest— I think right now it would be
an over-design at least for the basic protocol. Also, storing
'random' blocks has some locality problems,
Bringing the thread back on-topic:
On Wed, Apr 16, 2014 at 1:14 AM, Wladimir laa...@gmail.com wrote:
Hello,
Today I noticed that even my bank is warning people to not do internet
banking with Windows XP.
If it is no longer secure enough for online banking it's CERTAINLY not
secure enough to
On Tue, Apr 22, 2014 at 1:06 AM, Jan Møller jan.mol...@gmail.com wrote:
This is a very useful BIP, and I am very much looking forward to
implementing it in Mycelium, in particular for bip32 wallets.
I haven't seen commentary from you on the Kogelman draft, it would be
helpful there:
On Wed, Apr 23, 2014 at 12:55 AM, Mike Hearn m...@plan99.net wrote:
Lately someone launched Finney attacks as a service (BitUndo). As a reminder
for newcomers, Finney attacks are where a miner secretly works on a block
containing a double spend.
Hm? I didn't think this is at all what they did.
On Wed, Apr 23, 2014 at 1:44 PM, Adam Ritter arit...@gmail.com wrote:
Isn't a faster blockchain for transactions (maybe as a sidechain) solving
the problem? If there would be a safe way for 0-confirmation transactions,
the Bitcoin blockchain wouldn't even be needed.
Large scale consensus can't
On Wed, Apr 23, 2014 at 2:23 PM, Tier Nolan tier.no...@gmail.com wrote:
An interesting experiment would be a transaction proof of publication
chain.
Each transaction would be added to that chain when it is received. It could
be merge mined with the main chain.
If the size was limited, then
On Wed, Apr 23, 2014 at 2:42 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
In that case, maybe it makes sense to define another purpose id
without accounts as well already.
I believe many simple wallets will find multiple subwallets too
burdening for the user experience, or not worth the
On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. wtog...@gmail.com wrote:
If you are
a rare user who needs Bitcoin-Qt on an incompatible system you can at least
build it from source.
Tails users usually can't really build it from source— talks is a live
boot mostly stateless linux
On Thu, Apr 24, 2014 at 12:10 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin thoma...@gmx.de wrote:
Why do clients need to use the features in BIP 64? If Electrum doesn't want
to
use accounts, [...]
To clarify:
Electrum plans to have bip32
On Thu, Apr 24, 2014 at 12:58 AM, Mike Hearn m...@plan99.net wrote:
The complexity overhead is trivial - we already used coinbase scriptSigs for
voting on P2SH, I'm sure it'll be used for voting on other things in future
too.
We use coinbase sigs to gauge the safety of enforcing a soft fork
On Thu, Apr 24, 2014 at 1:39 AM, Mike Hearn m...@plan99.net wrote:
It absolutely is!
https://bitcointalk.org/index.php?topic=60937.0
May I direct your attention to the third post in that thread?
Luke attempting to ret-con the enforcement flag into a vote didn't
make it one, and certantly
On Fri, Apr 25, 2014 at 7:53 AM, Jim jim...@fastmail.co.uk wrote:
Oh dear.
For reasons that are perfectly reasonable we are close to losing any chance
of intra-client HD compatibility for BIP32 wallets.
In the next 12 months there will probably be collectively millions of users
of our new
On Fri, Apr 25, 2014 at 1:02 PM, Tier Nolan tier.no...@gmail.com wrote:
This looks reasonable from a brief skim over, but does not define any use
cases (it mentions necessary for atomic cross chain transfers, but does
not
explain how it is useful for that - perhaps that belongs in another BIP
On Fri, Apr 25, 2014 at 1:14 PM, Peter Todd p...@petertodd.org wrote:
Actually I did some work looking at this problem a few months ago and
other than somewhat larger transactions it looks like implementing
oracles by having the oracle reveal ECC secret keys works better in
every case. Notably
On Tue, Apr 29, 2014 at 7:13 AM, Mike Hearn m...@plan99.net wrote:
It only works if the majority of hashpower is controlled by attackers, in
which case Bitcoin is already doomed. So it doesn't matter at that point.
These parties wouldn't generally consider themselves attackers— nor
would many
101 - 200 of 322 matches
Mail list logo
