Kevin [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-03-03 to 2014-06-19
💬 Posted a total of 18 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:23:07

- reply

📅 Original date posted:2014-06-19
📝 Original message:On 6/19/2014 12:58 PM, Sergio Lerner wrote:
>
> I propose a setting that prevent mining pools AND reduce payoff
> variance which requires two changes: increasing the block-rate and
> changing the Bitcoin PoW (but still allowing current Bitcoin ASICs to
> work (as far as I know)). The block rate must be increased at least 20
> times and block must still be near full (e.g. there must be at least
> 20 more transactions/second than there is today)
>
> BlockPow is kind of PoW that only practically prevents mining pools
> for certain cryptocurrency settings based on concepts similar to
> parmacoin, but in a much simple degree. The idea is that if miners try
> to join a pool, then they incur in overhead of transmitting
> information and earn less than working solo. Let b (the payload)
> contain a full block. b must contain all the transactions and the
> header, and not only the transaction hashes. b should not hide
> anything. Let h be the block header (which contains the previous block
> hash and the Merkle tree root of the transactions). Let d be the
> difficulty. hash-block-length(b) returns the number of blocks
> processed by the hash function when fed with the block b. The target
> is divided by hash-block-length(b) so that the difficulty does not
> depend on the length of the block. Some other function can be used to
> encourage nodes to add more or less transactions.
>
> Def: Basic BlockPoW concept
>
> For each r in the nonce-range: if H ( H( r || b ) || h || r) ) < 2^-d/
> hash-block-length(b) then return r
>
> return null
>
> The header (h) is appended to the hashed message to allow SPV clients
> to verify the PoW without requiring the full block to be downloaded.
> Peers can send only (x,r,h) to SPV nodes, where x = H( r || b ), so
> they can verify the PoW. The verification procedure is obvious, and is
> skipped here. r is inserted at the beginning of the message to prevent
> pool administrators from keeping a secret mid-state of the hash
> function secret in order to prevent block stealing and also to force
> the miner to know b in the inner mining loop.
>
> So now mining requires the knowledge of the block b to be mined, and b
> must be received at each block-chain epoch. This could create an
> incentive not to include any transaction and use an almost empty b,
> because that way the bandwidth requirements is decreased. But this
> incentive should not exists normally, since by including transactions
> the solo miner gets an additional revenue from fees, which is lost if
> the block is empty. Anyway, to prevent this possible incentive we can
> append to b a subset of previous blocks (e.g 100 blocks). The block
> subset to include could be derived from a peudo-random function seeded
> by the previous block hash. Then a node would still need to download
> part or all the block-chain in order to mine.
>
> Now if the miner wants to be a dumb node and take part of a pool, then
> the current working unsolved block (the template) must be sent each
> time from the pool admin to each miner. If the pool admin hosts 1000
> miners, then to serve them with fresh block templates he needs 1000
> times more bandwidth that the miners, making this much more expensive.
> If miners create another network topology to distribute templates,
> they are incurring in the same overhead as being actively part of the
> cryptocurrency network, so they gain nothing.
>
> For example, in a block-chain with a 5 seconds block-rate, such as in
> NimbleCoin <http://nimbleCoin.org>, each block can be as large as 200
> Kbytes (100 tps are allowed). A miner will require the block template
> to be ready as fast as possible, say before 3 seconds, so as not to
> loose more than 60% of the times the transaction fees present in the
> block template. This means that a pool admin serving 1000 clients must
> have a upload bandwidth of at least 60 Mbytes/sec, and load balance
> servers, because all miners will demand the block template at the same
> time and will compete for it.
>
> The same miner, working solo, will not loose the 60% of block fees. If
> block fees are 10% of block reward, then solo miners earn 6% more than
> pool miners. Also, having a block rate of 5 seconds allows solo miners
> to receive payments more often and so it reduces the payment variance.
>
> This method to discourage mining pools only work as long as time is
> takes to transmit a block is comparable to the block interval time,
> e.g. 20%. This seems not to be a problem since if the cryptocurrency
> becomes popular, then we can expect blocks to be near full, while if
> is is not, then nobody will care about mining pools.
>
> For this method to work for Bitcoin, Bitcoin should reduce the block
> rate to at least 1 minute, and keep blocks of at least 10 Mbytes. Or
> go the NimbleCoin way, and reduce the block interval to 5 seconds. The
> sole reduction of the block rate from 10 minutes to 5 seconds would
> reduce notably the mining reward variance, which is the main reason
> miners don't mine solo.
>
> BitcoinBlockPow
>
> The basic BlockPoW is incompatible with Bitcoin ASICs as is but it can
> be made partially compatible with some tweaks: The value b is replaced
> by a a a subset or an integrity check of the block.
>
> Using a subset:
>
> First the hashMerkleRoot and hashPrevBlock fields are replaced by the
> fields: ChildBlock (32 bytes) and ScatteredBlockBytes (32 bytes).
> ChildBlock is the hash of a message with stores the old hashMerkleRoot
> and hashPrevBlock. ScatteredBlockBytes is a pseudo-random subset of
> bytes taken from the block template being mined. The seed for the
> pseudo-random function that selects the subset is the hashMerkleRoot
> plus the block time. When a miner scans all the 32bit nonce space,
> then a new hashMerkleRoot must be created to increase the extra-nonce
> field or the time must be updated. When this happens, a new subset of
> pseudo-random 32 block bytes must be collected. If the miner only
> stores 10% of the block template (e.g. 100 Kbytes instead of 1 Mbyte),
> then the probability he can build the ScatteredBlockBytes by
> brute-forcing the seed is 10^-32. If the miner performs 100 GH/sec,
> then the 32-bit nonce will overflow every 20 msec and the miner could
> request the ScatteredBlockBytes from the pool admin using a bandwidth
> of 1 Kbyte/s. A pool hosting 6 PH/sec (such as Eligious, which has 8%)
> would need to stream more than 60 Mb/s of ScatteredBlockBytes fields.
> A mining pool having 50% would need to stream 500 Mb/s, which is quite
> challenging. So miners will download the block normally, and become
> active part of the network.
>
> Using an integrity check:
>
> ScatteredBlockBytes is replaced by a field BlockHash defined as H(
> full-block-with-zero-nonce ). Obviously the header must be at the
> beginning of the block to force the re-hash.
>
> Best regards,
> Sergio.
>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Why do you want to punish pools?
--
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140619/47807d7c/attachment.html>

2023-06-07 15:22:15

- reply

📅 Original date posted:2014-06-03
📝 Original message:On 6/3/2014 12:29 AM, xor wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi,
>
> I thought a lot about the worst case scenario of SHA256d being broken in a way
> which could be abused to
> A) reduce the work of mining a block by some significant amount
> B) reduce the work of mining a block to zero, i.e. allow instant mining.
>
> Bitcoin needs to be prepared for this as any hash function has a limited
> lifetime. Usually crypto stuff is not completely broken instantly by new
> attacks but gradually. For example first the attack difficulty is reduced from
> 2^128 to 2^100, then 2^64, etc.
> This would make scenario A more likely.
>
> Now while B sounds more dangerous, I think in fact A is:
> Consider how A would happen in real life: Someone publishes a paper of a
> theoretical reduction of SHA256d attacks to 2^96 bit. Mathematicians will
> consider this as a serious attack and create a lot of riot.
> If no plan is made early enough, as in now, the Bitcoin Core team might then
> probably want to just do the easiest approach of replacing the hash function
> after a certain block number, i.e. a hard fork.
> But what about the Bitcoin miners, those who need to actually accept a change
> of mining algorithm which renders their hardware which cost MILLIONS
> completely worthless?
> Over the years they have gotten used to exponential growth of the Bitcoin
> networks hashrate, and therefore exponential devaluation of their mining
> hardware. Even if the attack on SHA256d causes a significant growth of
> difficulty, the miners will not *believe* that it is an actual attack on SHA256d
> - - maybe it is just some new large mining operation? They are used to this
> happening! Why should they believe this and switch to a new hash function
> which requires completely new hardware and therefore costs them millions?
> They will just keep mining SHA256d. Thats why this is more dangerous, because
> changing the hash funciton won't be accepted by the miners even though it is
> broken.
> Something smarter needs to be thought of.
>
> Now I must admit that I am not good at cryptography at all, but I had the
> following idea: Use the altcoin concept of having multiple hash functions in a
> chain. If SHA256d is broken, it is chained with a new hash function.
> Thereby, people who want to mine the new replacement hash function still will
> need ASICs which can solve the old SHA proof of work. So existing ASIC owners
> can amend their code to do SHA256d using the ASIC, and then the second hash
> function using a general purpose CPU.
> This would also allow a smooth migration of difficulty - I don't even know how
> difficulty would react with the naive approach of just replacing SHA with
> something else: It would probably be an unsolvable problem to define new rules
> to make it decrease enough so new blocks can actually be mined by the now
> several orders of magnitude slower CPU-only mining community but still be high
> enough to be able to deal with the fact that millions of people will try their
> luck with mining at the release date.
>
> While this sounds simple in theory, it might be a lot of work to implement, so
> you guys might want to take precautions for it soon :)
>
> Greetings,
> xor - A Freenet project developer
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
>
> iQIcBAEBCAAGBQJTjU9DAAoJEMtmZ+8tjWt5pNEP/2460eHu7ujrUSxinJXY7+wF
> E759/NcpNuakqu4NsS3ndi8lSiVIeixiOWZxPwLYkzC0pgPd5JrK5hdrYewsgreL
> Ltkh6LKB4YZLYrV3jm62ZPMTzCopYQ1l872xbN3PJQJoXhEp4fKu99++LDzVg9Gk
> n7rvrk6Iy/nSsZ1IMANpKghbU8/Gtn6ppCJv9rxRE//CZdTso1tTyOXXkEEMTHcV
> y/iv6CHXtTXPvOgEgciU0oCPq0NOUKdIAOD//ybcKzncOoHSmwr1rZdreCTH6/Ek
> 9uwq/HaQnseHPrq9qrIkIKrZDlnjKu7Tqw1BlbyBeCrWdJPCeDJg2kyCXgTvIzFD
> oXwZ6r16tb2QPR4ByyO1lZy9G2Pp26thk12BnadnPYTf1rMvsY15BjfUrCU9ppt/
> YpFAZSFlXUGOuOBKUznUeO8U1bXJylcTTnyER/cudOpcKR8Jt9l5tfm5LTHCB6Q2
> Tjmvsmd0BzwafLEhHD5FHoTZFNVdXWvEUO/w4I/2UWTS7CacbE1qk0rVpsF/4L1K
> /oFVnZIUKqsm5mMMb6WTQq+MjP2TF/eAAwm2UtFYmj0FVML9HBNwyiAc5UKwnD4Y
> Yq3Pl5QfRobwu6pgT3zO7vK+saOl8sePWbU8Skj41OTEDrJM4QIQGAqs1U8xke8+
> YnUYiyzreJ8ofHhNBs4/
> =dkuk
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
It is good to start thinking about such things. Let's face it, it could
happen. However, short of having bitcoin use another algorithm for
encryption, I am not sure much could be done. That's just me.
--
Kevin

2023-06-07 15:19:43

- reply

📅 Original date posted:2014-04-23
📝 Original message:On 4/23/2014 3:55 AM, Mike Hearn 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. When they eventually find
> a block, they run to the merchant and pay, then broadcast the block.
> In a simpler variant of this attack you make purchases as normal with
> a modified wallet that always submits a double spend to the service,
> and then N% of the time where N is the percentage of overall hash
> power the dishonest miners have, you get your money back minus their fee.
>
> N does not need to be very high to render Bitcoin much less useful.
> Real time transactions are very important. Although I never expected
> it when I first started using Bitcoin, nowadays most of my purchases
> with it are for food and drink. If Bitcoin could not support such
> purchases, I would use it much less.
> Even with their woeful security many merchants see <1-2% credit card
> chargeback rates, and chargebacks can be disputed. In fact merchants
> win about 40% of chargeback disputes. So if N was only, say, 5%, and
> there was a large enough population of users who were systematically
> trying to defraud merchants, we'd already be having worse security
> than magstripe credit cards. EMV transactions have loss rates in the
> noise, so for merchants who take those Bitcoin would be dramatically
> less secure.
>
> The idea of discouraging blocks that perform Finney attacks by having
> honest miners refuse to build on them has been proposed. But it has a
> couple of problems:
>
> 1. It's hard to automatically detect Finney attacks. Looking for
> blocks that contain unseen transactions that override the mempool
> doesn't work - the dishonest users could broadcast all their
> double spends once a Finney block was found and then broadcast the
> block immediately afterwards, thus making the block look like any
> other would in the presence of double spends.
>
> 2. If they could be automatically identified, it possibly could be
> converted into a DoS on the network by broadcasting double spends
> in such a way that the system races, and every miner produces a
> block that looks like a Finney attack to some of the others. The
> chain would stop advancing.
>
> 3. Miners who want to vote "no" on a block take a big risk, they
> could be on the losing side of the fork and end up wasting their work.
>
> We can resolve these problems with a couple of tweaks:
>
> 1. Dishonest blocks can be identified out of band, by having honest
> miners submit double spends against themselves to the service
> anonymously using a separate tool. When their own double spend
> appears they know the block is bad.
>
> 2. Miners can vote to reallocate the coinbase value of bad blocks
> before they mature. If a majority of blocks leading up to maturity
> vote for reallocation, the value goes into a pot that subsequent
> blocks are allowed to claim for themselves. Thus there is no risk
> to voting "no" on a block, the work done by the Finney attacker is
> not wasted, and users do not have to suffer through huge reorgs.
>
> This may seem a radical suggestion, but I think it's much less radical
> than some of the others being thrown around.
>
> The above approach works as long as the majority of hashpower is
> honest, defined to mean, working to stop double spending. This is the
> same security property as described in the white paper, thus this
> introduces no new security assumptions. Note that assuming
> /all/ miners are dishonest and are willing to double spend
> automatically resolves the Bitcoin experiment as a failure, because
> that would invalidate the entire theory upon which the system is
> built. That doesn't mean the assumption is wrong! It may be that an
> entirely unregulated market for double spending prevention cannot work
> and the participants eventually all end up trashing the commons - but
> the hope is that smart incentives can replace the traditional reliance
> on law and regulation to avoid this.
>
> The voting mechanism would only apply to coinbases, not arbitrary
> transactions, thus it cannot be used to steal arbitrary users
> bitcoins. A majority of miners can already reallocate coinbases by
> forking them out, but this wastes energy and work presenting a
> significant discouragement to vote unless you already know via some
> out of band mechanism that you have a solid majority. Placing votes
> into the coinbase scriptSig as is done with other things avoids that
> problem.
>
> The identification of Finney blocks relies on miners to take explicit
> action, like downloading and running a tool that submits votes via
> RPC. It can be expected that double spending services would try to
> identify and block the sentinel transactions, which is why it's better
> to have the code that fights this arms race be out of process and
> developed externally to Bitcoin Core itself, which should ultimately
> just enforce the new (forking) rule change.
>
>
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
I have some questions:
1. How can we work towards solving the double-spending problem?
2. Is it possible to "scan" for double-spending and correct it?
3. Is the network at large not secure enough?
--
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/e1e5bf4e/attachment.html>

2023-06-07 15:19:34

- reply

📅 Original date posted:2014-04-23
📝 Original message:On 4/23/2014 12:04 PM, Christophe Biocca wrote:
> It's not necessary that this "coinbase retribution" be either
> profitable or risk-free for this scheme to work. I think we should
> separate out the different layers of the proposal:
>
> 1. Attacking the coinbase instead of orphaning allows for 100 blocks'
> time for a consensus to be reached, rather than 10 minutes. This
> allows for human verification/intervention if needed (orphaning
> decisions would almost always need to be automated, due to the short
> timeframe). This is a useful insight, and I don't think it's been
> brought up before.
>
> 2. The original specification of how it's done (redistribution, no
> cost to voting) does seem exploitable. This can be fixed by reducing
> the incentive (burning instead of redistributing) and/or adding a risk
> to the orphaning attempts (a vote that fails destroys X bitcoins'
> worth from each voting block's own coinbase). The incentives can be
> tailored to mirror those of orphaning a block, to reduce the risk of
> abuse. Then the only difference from orphaning are 1) More limited
> rewriting of history (only the coinbase, vs all transactions in the
> block), and 2) More time to coordinate a response.
>
> 3. This proposal may be used for things other than punishing
> double-spend pools. In fact it might be used to punish miners for
> doing anything a significant percentage of hashpower dislikes (large
> OP_RETURNs, large blocks, gambling transactions, transactions banned
> by a government). But we can make the threshold higher than 51%, so
> that this doesn't turn into a significant risk (if 75% of hashpower is
> willing to enforce a rule, we're already likely to see it enforced
> through orphaning).
>
> On Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi <alex.mizrahi at gmail.com> wrote:
>>> And it still would. Non-collusive miners cast votes based on the outcome
>>> of their own attempts to double spend.
>>
>> Individually rational strategy is to vote for coinbase reallocation on every
>> block.
>>
>> Yes, in that case nobody will get reward. It is similar to prisoner's
>> dilemma: equilibrium has worst pay-off.
>> In practice that would mean that simple game-theoretic models are no longer
>> applicable, as they lead to absurd results.
>>
>>> I'm using it in the same sense Satoshi used it. Honest miners work to
>>> prevent double spends. That's the entire justification for their existence.
>>> Miners that are deliberately trying to double spend are worse than useless.
>>
>> Miners work to get rewards.
>> It absolutely doesn't matter whether they are deliberately trying to
>> double-spend or not: they won't be able to double-spend without a collusion.
>>
>> ------------------------------------------------------------------------------
>> Start Your Social Network Today - Download eXo Platform
>> Build your Enterprise Intranet with eXo Platform Software
>> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
>> Get Started Now And Turn Your Intranet Into A Collaboration Platform
>> http://p.sf.net/sfu/ExoPlatform
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
This all sounds verry restrictive. Is it possible to do a "sweep" in
order to "clean up" double spending? Why punish miners for the sake of
punishing them?
--
Kevin

2023-06-07 15:18:43

- reply

📅 Original date posted:2014-04-16
📝 Original message:On 4/16/2014 5:10 PM, Laszlo Hanyecz wrote:
> I think a warning like this is inappropriate.
>
> There are many reasons to use an out of date operating system and high level applications like wallets need not concern themselves with the rest of the system. Maybe the wallet can scan your browser cache and tell you to stop visiting somesite.com too?
>
> It just sounds like some kind of behavior modification that's being discussed here.. not-so-subtly suggesting that users shell out money for a newer version of the operating system, just to use their bitcoin wallets in a 'blessed' configuration. This actually sounds very similar to what happens with Apple iPhones.. they somehow manage to 'invalidate' the charging cables and accessories with every major software version. One day an accessory is working fine, then after the update users get a behavior modification nag every time they use it, urging them to buy a new one. Along these same lines, might as well put a warning about the registry keys needing to be cleaned, and maybe a 'shock the money' banner[1].
>
> You guys all know how it works with financial software - there are many organizations using decades old software (and hardware) because they know its shortcomings, they've taken care of them in a way that works them, and they don't want to start all over just for the sake of having the newest version.
>
> -Laszlo
>
> [1] http://www.buzzfeed.com/adobe/obnoxious-banner-ads-that-everyone-remembers
>
>
> On Apr 16, 2014, at 8:42 PM, Roy Badami <roy at gnomon.org.uk> wrote:
>
>> On Wed, Apr 16, 2014 at 05:20:41PM +0200, Pieter Wuille wrote:
>>> On Wed, Apr 16, 2014 at 5:12 PM, Kevin <kevinsisco61784 at gmail.com> wrote:
>>>> I think we should get to the bottom of this. Should we assume that xp is
>>>> not secure enough?
>>> Yes.
>> Do we need a similar warning for OS X 10.6? The EOL of that one is
>> *far* less well known than XP (because of Apple's failure to
>> communicate product lifecycles).
>>
>> roy
>>
>>
>>>> What is this warning?
>>> Windows XP is no longer maintained. Don't use such a system for
>>> protecting your money.
>>>
>>>> Who is issuing this warning?
>>> Microsoft: http://windows.microsoft.com/en-us/windows/end-support-help
>>>
>>> The suggestion here is to make Bitcoin Core detect when it's running
>>> on Windows XP, and warn the user (they are likely unaware of the
>>> risks).
>>>
>>> --
>>> Pieter
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Okay, so how about an autoupdate function which pulls a work around off
the server? Sooner or later, the vulnerabilities must be faced.
--
Kevin

2023-06-07 15:18:42

- reply

📅 Original date posted:2014-04-16
📝 Original message:On 4/16/2014 12:41 PM, Chris Williams wrote:
> It may not be our place to say whether XP is secure or not, but if we say that we support it then we have to run test passes against XP as a platform, and if an XP user reports a bug, then we have to do something to address it. So, it becomes a test and support issue, not a security issue.
>
> That's why it doesn't make sense to support an OS platform that the original vendor (MS) no longer supports themselves.
>
> On Apr 16, 2014, at 9:35 AM, Mark Friedenbach <mark at monetize.io> wrote:
>
>> On 04/16/2014 09:27 AM, Kevin wrote:
>>> Should we then add an alert message to wallet installers such as, "Such
>>> and such will not run on windows xp?"
>> It's not really our place to police that ... plus it's perfectly safe to
>> be running Bitcoin Core as a full node on XP. It's just the wallet
>> functionality that people should be careful about. We're talking about
>> such a small intersection of people who are running XP, have systems
>> powerful enough to run Bitcoin Core, and use the wallet functionality.
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Okay, so we simply stop supporting it. Should bitcoin pull support
altogether?
--
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140416/fbce3b17/attachment.html>

2023-06-07 15:18:41

- reply

📅 Original date posted:2014-04-16
📝 Original message:On 4/16/2014 11:28 AM, Wladimir wrote:
>
> On Wed, Apr 16, 2014 at 5:20 PM, Pieter Wuille
> <pieter.wuille at gmail.com <mailto:pieter.wuille at gmail.com>> wrote:
>
> On Wed, Apr 16, 2014 at 5:12 PM, Kevin <kevinsisco61784 at gmail.com
> <mailto:kevinsisco61784 at gmail.com>> wrote:
> > I think we should get to the bottom of this. Should we assume
> that xp is
> > not secure enough?
>
> Yes.
>
>
> It will quickly grow extremely insecure.
>
> People will be actively analyzing patches to post-XP versions to find
> security problems that are patched there, to see if they can be
> exploited on XP.
>
> Wladimir
>
Should we then add an alert message to wallet installers such as, "Such
and such will not run on windows xp?"
--
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140416/d88f01af/attachment.html>

2023-06-07 15:18:40

- reply

📅 Original date posted:2014-04-16
📝 Original message:On 4/16/2014 4:14 AM, Wladimir 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 run a wallet (for a node only it would be ok-ish as
> they have no keys to protect).
>
> Any opinions on what to do here? Just warn and allow the user to
> continue? Redirect them to a 'Windows XP is dangerous' message on
> bitcoin.org <http://bitcoin.org>? (Microsoft uses
> http://windows.microsoft.com/en-us/windows/end-support-help)
>
> The drawback of dropping XP support completely would be that a lot of
> computers (especially in China and Russia etc) are still running XP,
> so this could cause the network to lose nodes.
>
> If you're maintainer of other wallet software: how are you handling this?
> Are you going to drop XP support completely? If so, starting from when?
>
> Regards,
> Wladimir
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
I think we should get to the bottom of this. Should we assume that xp
is not secure enough? What is this warning? Who is issuing this warning?
--
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140416/25e492a7/attachment.html>

2023-06-07 15:18:27

- reply

📅 Original date posted:2014-04-09
📝 Original message:On 4/9/2014 11:29 AM, Wladimir wrote:
> Hello,
>
> This is primarily aimed at developers of SPV wallets.
>
> The recently reported decrease in number of full nodes could have
> several reasons, one of them that less people are running Bitcoin Core
> for the wallet because the other wallets are getting ahead in both
> features and useability.
>
> It's great to see innovation in wallets, but it's worrying that the
> number of full nodes decreases.
>
> It may be that lots of people would support the network by running a
> full node, but don't want to go through the trouble of installing
> bitcoin core separately (and get confused because it's a wallet, too).
>
> Hence I'd like to explore the idea of adding an option to popular SPV
> wallets, to spin a bitcoind process in the background. This could be
> pretty much transparent to the user - it would sync in the background,
> the wallet could show statistics about the node, but is not dependent
> on it.
>
> In exchange the user would get increased (full node level) security,
> as the SPV wallet would have a local trusted node.
>
> Does this sound like a good idea?
>
> Is there any way that Bitcoin Core can help to accomedate this
> 'embedded' usage? Specific Interfaces, special builds - maybe add a
> walletless bitcoind build to gitian - bindings, dlls, etc?
>
> Wladimir
>
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
I personally like the ida. Are you talking about a flag that could
toggle this "in the background" mode or recoding for in the background use?
--
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/a35b1353/attachment.html>

2023-06-07 15:17:03

- reply

📅 Original date posted:2014-04-02
📝 Original message:On 4/2/2014 12:55 PM, Jud wrote:
> Looks like Kevin was probably trying to point us to his fork for comments:
>
> https://github.com/kjsisco/bitcoin/tree/patch-1
>
> --
> Jud
>
> On Wednesday, April 2, 2014 at 12:45 PM, Laszlo Hanyecz wrote:
>
>> Maybe he has a fork on the real github.com <http://github.com> and
>> the link was a mistake.
>>
>> http://news.nurse.com/article/20121203/NY02/112030026#.Uzw5UVy2uw8
>>
>> I think it's possible that 'Kevin' is for real and maybe he doesn't
>> realize he linked to a phishing site, if it was an accident. If this
>> is the same person, then he's blind, and maybe that's why he wrote 'U
>> R L' instead of the usual 'URL', by using speech to text or some
>> other assistive tech. It might be that he tried to fork
>> github.com/bitcoin/bitcoin <http://github.com/bitcoin/bitcoin> and
>> just provided the wrong link. But regardless, stay away from the one
>> with two Bs in it.
>>
>> Thanks,
>> Laszlo
>>
>>
>> On Apr 2, 2014, at 3:59 PM, Kevin <kevinsisco61784 at gmail.com
>> <mailto:kevinsisco61784 at gmail.com>> wrote:
>>
>>> On 4/2/2014 11:45 AM, Ricardo Filipe wrote:
>>>> Kevin,
>>>> the thing is you gave us a bad link... what is the correct URL of
>>>> your project?
>>>>
>>>> 2014-04-02 16:30 GMT+01:00 Kevin <kevinsisco61784 at gmail.com
>>>> <mailto:kevinsisco61784 at gmail.com>>:
>>>>> On 4/2/2014 11:13 AM, Laszlo Hanyecz wrote:
>>>>>> Maybe this site serves up exploits selectively? I'm guessing most
>>>>>> people are getting the 'domain for sale' but whoever is the
>>>>>> target probably gets something special?
>>>>>>
>>>>>> On Apr 2, 2014, at 2:53 PM, Kevin <kevinsisco61784 at gmail.com
>>>>>> <mailto:kevinsisco61784 at gmail.com>> wrote:
>>>>>>
>>>>>>> On 4/2/2014 9:08 AM, Jeff Garzik wrote:
>>>>>>>> At first, this is a poor choice of URL.
>>>>>>>>
>>>>>>>> But it really looks like a phishing attempt that no one should
>>>>>>>> visit.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Apr 1, 2014 at 4:00 PM, Kevin
>>>>>>>> <kevinsisco61784 at gmail.com <mailto:kevinsisco61784 at gmail.com>>
>>>>>>>> wrote:
>>>>>>>>> I've sat on this for some time after starting this. I have
>>>>>>>>> forked this
>>>>>>>>> from bitcoin core and am working on a secure tax "mode" for
>>>>>>>>> bitcoin. It
>>>>>>>>> is written in Autoit. I know I know, scripting language alert!
>>>>>>>>> I would
>>>>>>>>> like people to look at:
>>>>>>>>> http://www.githubb.com/bitcoin/bitcoin
>>>>>>>>> Look at it, and let's have an open dialog about it. I want to
>>>>>>>>> know the
>>>>>>>>> good, the bad, and the ugly!
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Kevin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> _______________________________________________
>>>>>>>>> Bitcoin-development mailing list
>>>>>>>>> Bitcoin-development at lists.sourceforge.net
>>>>>>>>> <mailto:Bitcoin-development at lists.sourceforge.net>
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>>>> As far as choice of U R L, it may be a poor choice but I did this
>>>>>>> because I wanted it connected with the core. As far as fishing it
>>>>>>> certainly is not that! This is a serious project.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Kevin
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> _______________________________________________
>>>>>>> Bitcoin-development mailing list
>>>>>>> Bitcoin-development at lists.sourceforge.net
>>>>>>> <mailto:Bitcoin-development at lists.sourceforge.net>
>>>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>> I tell you that this is a serious project for bitcoin. You are free to
>>>>> assume the worst. After all, I did say the good the bad and the ugly
>>>>> would come out of this. I happen to be a big believer in bitcoin and I
>>>>> feel this project holds water. If you disagree, that's fine.
>>>>>
>>>>>
>>>>> --
>>>>> Kevin
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> Bitcoin-development mailing list
>>>>> Bitcoin-development at lists.sourceforge.net
>>>>> <mailto:Bitcoin-development at lists.sourceforge.net>
>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>> I understand now why someone thought I was fishing. That link should
>>> work just fine...I'm not sure what the problem is as I know I forked
>>> correctly. I guess I'll need to register a domain for it an get a
>>> page going and link from there. I just haven't gotten around to it
>>> but will do that. I'll get going! Just know that I would never set
>>> up fishing; that's not my style.
>>>
>>>
>>> --
>>> Kevin
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> <mailto:Bitcoin-development at lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
I was trying to point you to that. I am embarrassed.
--
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140402/8fff8e1f/attachment.html>

2023-06-07 15:17:02

- reply

📅 Original date posted:2014-04-02
📝 Original message:On 4/2/2014 12:45 PM, Laszlo Hanyecz wrote:
> Maybe he has a fork on the real github.com and the link was a mistake.
>
> http://news.nurse.com/article/20121203/NY02/112030026#.Uzw5UVy2uw8
>
> I think it's possible that 'Kevin' is for real and maybe he doesn't realize he linked to a phishing site, if it was an accident. If this is the same person, then he's blind, and maybe that's why he wrote 'U R L' instead of the usual 'URL', by using speech to text or some other assistive tech. It might be that he tried to fork github.com/bitcoin/bitcoin and just provided the wrong link. But regardless, stay away from the one with two Bs in it.
>
> Thanks,
> Laszlo
>
>
> On Apr 2, 2014, at 3:59 PM, Kevin <kevinsisco61784 at gmail.com> wrote:
>
>> On 4/2/2014 11:45 AM, Ricardo Filipe wrote:
>>> Kevin,
>>> the thing is you gave us a bad link... what is the correct URL of your project?
>>>
>>> 2014-04-02 16:30 GMT+01:00 Kevin <kevinsisco61784 at gmail.com>:
>>>> On 4/2/2014 11:13 AM, Laszlo Hanyecz wrote:
>>>>> Maybe this site serves up exploits selectively? I'm guessing most people are getting the 'domain for sale' but whoever is the target probably gets something special?
>>>>>
>>>>> On Apr 2, 2014, at 2:53 PM, Kevin <kevinsisco61784 at gmail.com> wrote:
>>>>>
>>>>>> On 4/2/2014 9:08 AM, Jeff Garzik wrote:
>>>>>>> At first, this is a poor choice of URL.
>>>>>>>
>>>>>>> But it really looks like a phishing attempt that no one should visit.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Apr 1, 2014 at 4:00 PM, Kevin <kevinsisco61784 at gmail.com> wrote:
>>>>>>>> I've sat on this for some time after starting this. I have forked this
>>>>>>>> from bitcoin core and am working on a secure tax "mode" for bitcoin. It
>>>>>>>> is written in Autoit. I know I know, scripting language alert! I would
>>>>>>>> like people to look at:
>>>>>>>> http://www.githubb.com/bitcoin/bitcoin
>>>>>>>> Look at it, and let's have an open dialog about it. I want to know the
>>>>>>>> good, the bad, and the ugly!
>>>>>>>>
>>>>>>>> --
>>>>>>>> Kevin
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> _______________________________________________
>>>>>>>> Bitcoin-development mailing list
>>>>>>>> Bitcoin-development at lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>>> As far as choice of U R L, it may be a poor choice but I did this
>>>>>> because I wanted it connected with the core. As far as fishing it
>>>>>> certainly is not that! This is a serious project.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Kevin
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> _______________________________________________
>>>>>> Bitcoin-development mailing list
>>>>>> Bitcoin-development at lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>> I tell you that this is a serious project for bitcoin. You are free to
>>>> assume the worst. After all, I did say the good the bad and the ugly
>>>> would come out of this. I happen to be a big believer in bitcoin and I
>>>> feel this project holds water. If you disagree, that's fine.
>>>>
>>>>
>>>> --
>>>> Kevin
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> I understand now why someone thought I was fishing. That link should work just fine...I'm not sure what the problem is as I know I forked correctly. I guess I'll need to register a domain for it an get a page going and link from there. I just haven't gotten around to it but will do that. I'll get going! Just know that I would never set up fishing; that's not my style.
>>
>>
>> --
>> Kevin
>>
Thank you for giving me the benifit of the doubt. I did not realize my
mistake. I hope we can now get back to talking about bitcoin
--
Kevin

2023-06-07 15:17:02

- reply

📅 Original date posted:2014-04-02
📝 Original message:On 4/2/2014 11:45 AM, Ricardo Filipe wrote:
> Kevin,
> the thing is you gave us a bad link... what is the correct URL of your project?
>
> 2014-04-02 16:30 GMT+01:00 Kevin <kevinsisco61784 at gmail.com>:
>> On 4/2/2014 11:13 AM, Laszlo Hanyecz wrote:
>>> Maybe this site serves up exploits selectively? I'm guessing most people are getting the 'domain for sale' but whoever is the target probably gets something special?
>>>
>>> On Apr 2, 2014, at 2:53 PM, Kevin <kevinsisco61784 at gmail.com> wrote:
>>>
>>>> On 4/2/2014 9:08 AM, Jeff Garzik wrote:
>>>>> At first, this is a poor choice of URL.
>>>>>
>>>>> But it really looks like a phishing attempt that no one should visit.
>>>>>
>>>>>
>>>>> On Tue, Apr 1, 2014 at 4:00 PM, Kevin <kevinsisco61784 at gmail.com> wrote:
>>>>>> I've sat on this for some time after starting this. I have forked this
>>>>>> from bitcoin core and am working on a secure tax "mode" for bitcoin. It
>>>>>> is written in Autoit. I know I know, scripting language alert! I would
>>>>>> like people to look at:
>>>>>> http://www.githubb.com/bitcoin/bitcoin
>>>>>> Look at it, and let's have an open dialog about it. I want to know the
>>>>>> good, the bad, and the ugly!
>>>>>>
>>>>>> --
>>>>>> Kevin
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> _______________________________________________
>>>>>> Bitcoin-development mailing list
>>>>>> Bitcoin-development at lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>> As far as choice of U R L, it may be a poor choice but I did this
>>>> because I wanted it connected with the core. As far as fishing it
>>>> certainly is not that! This is a serious project.
>>>>
>>>>
>>>> --
>>>> Kevin
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> I tell you that this is a serious project for bitcoin. You are free to
>> assume the worst. After all, I did say the good the bad and the ugly
>> would come out of this. I happen to be a big believer in bitcoin and I
>> feel this project holds water. If you disagree, that's fine.
>>
>>
>> --
>> Kevin
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
I understand now why someone thought I was fishing. That link should
work just fine...I'm not sure what the problem is as I know I forked
correctly. I guess I'll need to register a domain for it an get a page
going and link from there. I just haven't gotten around to it but will
do that. I'll get going! Just know that I would never set up fishing;
that's not my style.
--
Kevin

2023-06-07 15:17:00

- reply

📅 Original date posted:2014-04-02
📝 Original message:On 4/2/2014 11:13 AM, Laszlo Hanyecz wrote:
> Maybe this site serves up exploits selectively? I'm guessing most people are getting the 'domain for sale' but whoever is the target probably gets something special?
>
> On Apr 2, 2014, at 2:53 PM, Kevin <kevinsisco61784 at gmail.com> wrote:
>
>> On 4/2/2014 9:08 AM, Jeff Garzik wrote:
>>> At first, this is a poor choice of URL.
>>>
>>> But it really looks like a phishing attempt that no one should visit.
>>>
>>>
>>> On Tue, Apr 1, 2014 at 4:00 PM, Kevin <kevinsisco61784 at gmail.com> wrote:
>>>> I've sat on this for some time after starting this. I have forked this
>>>> from bitcoin core and am working on a secure tax "mode" for bitcoin. It
>>>> is written in Autoit. I know I know, scripting language alert! I would
>>>> like people to look at:
>>>> http://www.githubb.com/bitcoin/bitcoin
>>>> Look at it, and let's have an open dialog about it. I want to know the
>>>> good, the bad, and the ugly!
>>>>
>>>> --
>>>> Kevin
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>> As far as choice of U R L, it may be a poor choice but I did this
>> because I wanted it connected with the core. As far as fishing it
>> certainly is not that! This is a serious project.
>>
>>
>> --
>> Kevin
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
I tell you that this is a serious project for bitcoin. You are free to
assume the worst. After all, I did say the good the bad and the ugly
would come out of this. I happen to be a big believer in bitcoin and I
feel this project holds water. If you disagree, that's fine.
--
Kevin

2023-06-07 15:17:00

- reply

📅 Original date posted:2014-04-02
📝 Original message:On 4/2/2014 9:08 AM, Jeff Garzik wrote:
> At first, this is a poor choice of URL.
>
> But it really looks like a phishing attempt that no one should visit.
>
>
> On Tue, Apr 1, 2014 at 4:00 PM, Kevin <kevinsisco61784 at gmail.com> wrote:
>> I've sat on this for some time after starting this. I have forked this
>> from bitcoin core and am working on a secure tax "mode" for bitcoin. It
>> is written in Autoit. I know I know, scripting language alert! I would
>> like people to look at:
>> http://www.githubb.com/bitcoin/bitcoin
>> Look at it, and let's have an open dialog about it. I want to know the
>> good, the bad, and the ugly!
>>
>> --
>> Kevin
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
As far as choice of U R L, it may be a poor choice but I did this
because I wanted it connected with the core. As far as fishing it
certainly is not that! This is a serious project.
--
Kevin

2023-06-07 15:16:59

- reply

📅 Original date posted:2014-04-01
📝 Original message:I've sat on this for some time after starting this. I have forked this
from bitcoin core and am working on a secure tax "mode" for bitcoin. It
is written in Autoit. I know I know, scripting language alert! I would
like people to look at:
http://www.githubb.com/bitcoin/bitcoin
Look at it, and let's have an open dialog about it. I want to know the
good, the bad, and the ugly!
--
Kevin

2023-06-07 15:14:48

- reply

📅 Original date posted:2014-03-05
📝 Original message:Hello. How would I submit a patch? Could it be sent through the list
as an attachment?
--
Kevin

2023-06-07 15:14:41

- reply

📅 Original date posted:2014-03-05
📝 Original message:On 3/5/2014 7:49 AM, Mike Hearn wrote:
> A new practical technique has been published that can recover
> secp256k1 private keys after observing OpenSSL calculate as little as
> 200 signatures:
>
> http://eprint.iacr.org/2014/161.pdf
>
> This attack is based on the FLUSH+RELOAD technique published last
> year. It works by observing L3 CPU cache timings and forcing cache
> line flushes using the clflush opcode. As a result, it is applicable
> to any x86 environment where an attacker may be able to run on the
> same hardware i.e. virtualised hosting environments where keys are
> being reused.
>
> I am not currently aware of any efforts to make OpenSSL's secp256k1
> implementation completely side channel free in all aspects. Also,
> unfortunately many people have reimplemented ECDSA themselves and even
> if OpenSSL gets fixed, the custom implementations probably won't.
>
> So, IMHO this is a sign for hot wallet users to start walking (but not
> running) towards the exits of these shared cloud services: it doesn't
> feel safe to sign transactions on these platforms, so hot wallets
> should be managed by dedicated hardware. Of course other parts of the
> service, like the website, are less sensitive and can still run in the
> cloud. I doubt the researchers will release their code to do the side
> channel attack and it's rather complex to reimplement, so this gives
> some time for mitigation. Unfortunately the huge sums being held in
> some "bitbank" style hot wallets mean that attackers are well
> motivated to pull off even quite complex attacks.
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
How can we patch this issue?
--
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140305/64ceb7da/attachment.html>

2023-06-07 15:14:36

- reply

📅 Original date posted:2014-03-03
📝 Original message:Hello. I am a developer and I wish to contribute to bitcoin. Where is
the best place to start?
--
Kevin