Re: [Bitcoin-development] Question regarding transactions with NLOCKTIME > 0

[s7r]

Hi,

Well, depends on your model and what you want to achieve. That would
depend on each wallet, I couldn't confirm nor deny that this is or isn't
true. You have to check with your wallet how it handles transactions
with nLockTime. Maybe you are the one who generates the nLockTime
transaction,  but that needs to be broadcasted by the payee (your
recipient) when the locktime expires?

One way I would use nLockTime is to have the tx generated, and keep it
somewhere not related to my wallet(s) until the nLockTime expires, then
I can broadcast it to the network by /sendrawtransaction and have it
mined and included into a block.


On 6/21/2015 3:11 PM, Braun Brelin wrote:
> So, basically it sounds as though the wallet generating the transaction
> is what is responsible for holding on to the transaction and then
> only releasing it to the network when the NLOCKTIME value is less than
> or equal to the current time.  Does that sound right?  
> 
> Braun
> 
> 
> On Sun, Jun 21, 2015 at 10:45 AM, s7r  <mailto:s...@sky-ip.org>> wrote:
> 
> Hi
> 
> I don't think that a transaction with nLockTime>0 will be accepted by
> nodes / relayed in the Bitcoin network, until its time expires (e.g.
> nLockTime==now). This means it obviously cannot be stored in a block,
> before its locktime expires. nLockTime is designed in a way that you,
> need to keep it offline (not broadcast it to the network because it
> won't be accepted or relayed by nodes) until the locktime expires, then
> you can broadcast it and it will be mined and included in a block, like
> a normal tx.
> 
> This is exactly why Peter Todd and others are working on
> CHECKLOCKTIMEVERIFY and RELATIVE CHECKLOCKTIMEVERIFY - this is an
> enhancement to basic nLockTime which tends to offer to users the
> guarantee that if you have a transaction with nLockTime, the signer
> holding the private keys used to sign it cannot sign another one, with
> nLockTime 0 and broadcast it before the locktime for your tx expires.
> 
> Cheers!
> 
> On 6/21/2015 10:10 AM, Braun Brelin wrote:
> > Hi all,
> >
> > When a transaction with N_LOCKTIME>0 is created, does that transaction
> > get stored in a block on the blockchain or is it stored in the mempool
> > until the actual time (or block number) exceeds the current value?  If
> > it is stored on the blockchain, how does that affect the concept of
> > pruning that is supposed to be going in to version 0.11?  I.e. if I
> > create a transaction that doesn't take effect for 10 years, and that
> > transaction is stored in a block, does that block stay on the active
> > list for that period of time?
> >
> > Thanks,
> >
> > Braun Brelin
> >
> >
> >
> >
> 
> --
> >
> >
> >
> > ___
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> <mailto:Bitcoin-development@lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> 
> 

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Question regarding transactions with NLOCKTIME > 0

[s7r]

Hi

I don't think that a transaction with nLockTime>0 will be accepted by
nodes / relayed in the Bitcoin network, until its time expires (e.g.
nLockTime==now). This means it obviously cannot be stored in a block,
before its locktime expires. nLockTime is designed in a way that you,
need to keep it offline (not broadcast it to the network because it
won't be accepted or relayed by nodes) until the locktime expires, then
you can broadcast it and it will be mined and included in a block, like
a normal tx.

This is exactly why Peter Todd and others are working on
CHECKLOCKTIMEVERIFY and RELATIVE CHECKLOCKTIMEVERIFY - this is an
enhancement to basic nLockTime which tends to offer to users the
guarantee that if you have a transaction with nLockTime, the signer
holding the private keys used to sign it cannot sign another one, with
nLockTime 0 and broadcast it before the locktime for your tx expires.

Cheers!

On 6/21/2015 10:10 AM, Braun Brelin wrote:
> Hi all, 
> 
> When a transaction with N_LOCKTIME>0 is created, does that transaction
> get stored in a block on the blockchain or is it stored in the mempool
> until the actual time (or block number) exceeds the current value?  If
> it is stored on the blockchain, how does that affect the concept of
> pruning that is supposed to be going in to version 0.11?  I.e. if I
> create a transaction that doesn't take effect for 10 years, and that
> transaction is stored in a block, does that block stay on the active
> list for that period of time?
> 
> Thanks,
> 
> Braun Brelin
> 
> 
> 
> --
> 
> 
> 
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Is SourceForge still trustworthy enough to host this list?

[s7r]

The mail list is public, so it's not like the data on it is somehow
sensitive. Sourcefoge is fine, it has a nice web UI where you can browse
the message and sort/order them as you want, etc.

Why would you want to move to a paid solution? And why would you want
users to have to pay per message? This is the worst idea ever from my
point of view. We want to encourage people to join the community, run
full nodes, ask questions, come with solutions, ideas for improvements
and so on. Everyone should read and write and contribute as much as
possible with ideas in debates. You never know who can have bright ideas
in some contexts.

Bottom line is so far sourceforge handles the mail lists just fine. I
don't see a single advantage another mail list provider / system could
offer, except some headache and extra work for migration. The software
distribution via sourcefoge was cancelled for obvious reasons which I
fully understand and agree to, but it has nothing to do with the mail
lists. We have way more important things to brainstorm about.

On 6/10/2015 7:46 PM, Andy Schroder wrote:
> Regarding changing the e-mail list provider. Is anyone interested in 
> sponsoring it? There are non-free options, but it may be difficult to 
> always ensure the fee is being paid to the provider. I think finding an 
> agreeable free solution may have been the issue before? I've also 
> thought of trying to make a pay per message or byte solution (and this 
> cost could be dynamic based upon the number of current mailing list 
> subscribers). This could solve the who pays problem (the sender pays), 
> as well as motivate people to be more concise and clear with their 
> messages, and at the same time limit spam.
> 
> 
> 
> Any thoughts?
> 
> Andy Schroder
> 
> On 06/10/2015 05:35 AM, Wladimir J. van der Laan wrote:
>> On Wed, Jun 10, 2015 at 10:25:12AM +0200, xor wrote:
>>> http://www.howtogeek.com/218764/warning-don%E2%80%99t-download-software-from-sourceforge-if-you-can-help-it/
>> All our downloads (even old ones) have recently been deleted from 
>> sourceforge, for this reason. They haven't been mentioned in Bitcon Core 
>> release announcements for a long time.
>>
>> No opinion on the mailing list. Though I think it's less urgent. The issue 
>> of moving the mailinglist has come up before a few times and people can't 
>> agree where to move to.
>>
>> Wladimir
>>
>>
>> --
> 
> 
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal: A measured response to save Bitcoin Core

[s7r]

Hi,

For the less crypto engineering experts but highly interested in Bitcoin
and working with Bitcoin on daily basis reading the list, what would be
an easy to understand explanation about how does this solution represent
a good fix?

So, we have a hard cap of 1 MB block currently. This is not enough
because more and more people use Bitcoin and the transaction volume
increased (yeey, good news). So, rather than fixing the issue for good,
we just increase the block size hard cap to 20 MB. I will not discuss if
this causes problems or not. But what are the future plans, when the 20
MB hard cap will be reached? Increase it again? This doesn't sound like
a fix, it sounds more like pushing the can down the road. Obviously if 1
MB is not enough now, we have the reasonable suspicion that 20 MB could
not be enough in few years.

What is the explanation that 20 MB blocks will be sufficient for life
time? Is it because 'probably other solutions will appear, such as
micropayment channels and offchain transactions'?  If this is the case,
those can easily function with 1 MB blocks as well, and we should see
those in action sooner rather than later.

I run multiple full nodes, including one with Bitcoin XT and I don't
want to see Bitcoin XT and Bitcoin Core divide into different consensus
and create 2 altcoins instead of one Bitcoin.

On 5/31/2015 3:29 AM, Matt Whitlock wrote:
> Greg, Pieter, Jeff, and Wladimir,
> 
> I'll try to be brief to respect your time.
> 
> 1. I don't want to see Bitcoin die.
> 
> 2. As has been discussed on this list and elsewhere: Bitcoin could 
> potentially die due to economic and/or game-theoretic complications arising 
> from raising the block size limit, but Bitcoin could also die due to 
> usability complications arising from NOT raising the block size limit. 
> Strong, personally held opinions by various members of this community 
> notwithstanding, it is not clear which of these scenarios is more likely.
> 
> 3. What *is* clear at this point is that Gavin will move ahead with his 
> proposal, regardless of whether the remainder of the Bitcoin Core committers 
> agree with him. If he has to commit his changes to Bitcoin XT and then rally 
> the miners to switch, then that's what he'll do. He believes that he is 
> working in the best interests of Bitcoin (as I would hope we all do), and so 
> I do not fault him for his intentions. However, I think his proposal is too 
> risky.
> 
> 4. I also think that ignoring the immediate problem is too risky. If allowing 
> significantly larger blocks will cause a serious problem for Bitcoin (which 
> is a possibility that we cannot rule out, as we lack omniscience), then NOT 
> making any change to Bitcoin Core will virtually *assure* that we cause 
> exactly this problem, as the popular (non-technical) consensus appears to be 
> in favor of Bitcoin XT and a larger block size limit. If we do nothing, then 
> there's a very real chance that Bitcoin XT takes over, for better or worse.
> 
> 5. I'd like to propose a way that we can have our cake and eat it too. My 
> proposal attempts to satisfy both those who want larger blocks AND those who 
> want to be extremely cautious about changing the fundamental economic 
> parameters of Bitcoin.
> 
> 6. Something I've never understood about Gavin's (et al.) proposal is why 
> there is a massive step right up front. Assuming we accept his argument that 
> we're critically close to running out of capacity, I still must ask: why do 
> we need a 20x increase all at once?
> 
> 7. It's not a given that blocks will immediately expand to meet the hard 
> limit. In fact, there are strong and compelling arguments why this will NOT 
> happen. But in any software system, if a given scenario is *possible*, then 
> one MUST assume that it will happen and must have a plan to handle it.
> 
> 8. My primary objection is not to raising the block size limit; my objection 
> is to raising it *suddenly*. You can argue that, because we'll have plenty of 
> time before March 2016, it's not "sudden," but, whether we do it now or a 
> year from now or a decade from now, a step function is, by definition, sudden.
> 
> 9. My proposal is that we raise the block size limit *gradually*, using an 
> approximately smooth function, without a step discontinuity. We can employ a 
> linear growth function to adjust the block size limit *smoothly* from 1 MB to 
> 20 MB over the course of several years, beginning next March.
> 
> 10. This is the difference between cannonballing into the deep end of the 
> pool and walking gingerly down the steps into the shallow end. Both get you 
> to the eventual goal, but one is reckless while the other is measured and 
> deliberate. If there's a problem that larger blocks will enable, then I'd 
> prefer to see the problem crop up gradually rather than all at once. If it's 
> gradual, then we'll have time to discuss and fix it without panicking.
> 
> 11. I am offering to implement this proposal and submit a pu

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

[s7r]

On 5/28/2015 4:35 PM, Tier Nolan wrote:
> On Thu, May 28, 2015 at 1:04 PM, Peter Todd  > wrote:
> 
> For that matter, we probably don't want to treat this as a *version*
> change, but rather a *feature* flag. 
> 
> 
> I think it is still a version change.  At the moment, the 4 bytes refer
> to the sequence number and afterwards they mean something else.
> 
> For relative locktime verify, I think most use cases could be block
> count based and don't need to be able to count very high. 
> 
> I think the main benefit is that protocols can have one party trigger a
> step while giving the other party guaranteed time to respond.
> 
> *Fast Channel Close
> *
> 
> This assumes that malleability is fixed.
> 

Indeed. This is very important for refunds.

> Alice creates
> 
> TXA:
> output (x) to [multisig A1 & B1]
> 
> Refund:
> input TXA (signed by Alice)
> Output [(A2 & relative_check_locktime(150)) OR (multisig A3 &  B2)]
> 
> Alice sends Refund to Bob
> 
> Bob signs it and sends it back to Alice
> 
> Alice verifies the signature, adds her own and sends it to Bob.
> 
> She broadcasts TXA (would wait until Bob confirms acceptance).
> 
> This means that both Alice and Bob have the refund transaction and can
> use it to close the channel (assuming TXA is not mutated).
> 

In this scenario, if channel is closed, Alice is the only one who can
take the coins back after a relative locktime of 150 blocks. Bob is not
able to do this.

> Alice can send money to Bob by creating a transaction which spends the
> output of the refund transaction (splitting the output x-b for Alice and
> b for Bob), signing it and sending it to Bob.
> 
> Alice can force Bob to close the channel by broadcasting the refund
> transaction.  150 blocks later, she gets the channel deposit if he
> doesn't act.
> 

How is Bob protected in this scenario? If Alice sings a transaction
which spends the output of the refund transaction and gives it to Bob,
Bob can just add its signature and claim his slice of the output,
without necessarily shipping the goods or delivering the services to Alice.

> If she had sent some money to Bob, he has 150 blocks to sign the
> transaction that pays him the most money and broadcast it.  Alice gets
> the remainder of the deposit.
> 
Can you be more explicit here? It doesn't make sense for me.

> Alice cannot broadcast earlier version, since Bob doesn't send her the
> signed versions.
> 
> This means that the channel doesn't need a defined end date.  Either
> party can close the channel whenever they want.
> 
With some risks.

> TXA could be protected against malleability by adding a locktime path. 
> This would only be for use if the transaction is mutated.
> 
How do you apply a locktime path to a tx in the current network consensus?

> 
> --
> 
> 
> 
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

[s7r]

Hi Peter,

Thanks for your reply.

I know and bookmarked your branch - nice work.

So, to clarify:
- bitcoin core (official / default) 0.10.x currently has First-seen
mempool behavior
- your custom branch uses replace by fee mempool behavior which allows
an user to change anything in a tx (I guess it needs just to have at
least one same input, so it can link it to another previously signed tx
with lower fee and substitute it in the mempool, correct?).

- First Seen Safe Replace by Fee (FSF-RBF) mempool behavior which allows
an user only to add inputs and/or increase the value of outputs will be
in yet another branch, maintained by you, but not in default / official
bitcoin core?

Another thing, if FSF-RBF lets you change TXes in the manner described
above, how does the client know which tx needs to be replaced in the
mempool? Since the txid naturally changes. How does it map tx1 with tx2
(to know tx2 has a higher fee and needs to substitute tx1) if quite a
lot of params from the transaction structure can change?

Thanks!

On 5/27/2015 4:25 AM, Peter Todd wrote:
> On Wed, May 27, 2015 at 12:29:28AM +0300, s7r wrote:
>> What is wrong with the man testing some ideas on his custom branch? This
>> is how improvements come to life. I saw in the BIPs some really
>> interesting ideas and nice brainstorming which came from Peter Todd.
>>
>> Now, my question, if replace by fee doesn't allow me to change the
>> inputs or the outputs, I can only add outputs... what can I do with this
>> feature? If I sent a tx and want to replace it with a higher fee one,
>> the higher fee one can only have maybe additional change addresses or
>> another payment, if the inputs suffice? Do we have any real use cases?
> 
> You're a bit mistaken there: standard RBF lets you change anything, and
> FSS RBF lets you modify inputs and add outputs and/or make the value of
> outputs higher.
> 
>> P.S. is it planned to include this by default in bitcoin core 10.0.3 or
>> it will remain just on Peter's branch?
> 
> Any significant change to mempool policy like RBF is very unlikely to be
> incorporated in the Bitcoin Core v0.10.x branch, simply because it'd be
> too large a change for a minor, mostly bugfix, release.
> 
> Having said that, I already maintain a standard RBF branch for v0.10.x,
> and have been asked by a major minor to backport FSS RBF for v0.10.x as
> well.
> 

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

[s7r]

What is wrong with the man testing some ideas on his custom branch? This
is how improvements come to life. I saw in the BIPs some really
interesting ideas and nice brainstorming which came from Peter Todd.

Now, my question, if replace by fee doesn't allow me to change the
inputs or the outputs, I can only add outputs... what can I do with this
feature? If I sent a tx and want to replace it with a higher fee one,
the higher fee one can only have maybe additional change addresses or
another payment, if the inputs suffice? Do we have any real use cases?

P.S. is it planned to include this by default in bitcoin core 10.0.3 or
it will remain just on Peter's branch?

On 5/26/2015 11:30 PM, joli...@airmail.cc wrote:
> You're the Chief Scientist of __ViaCoin__ a alt with 30 second blocks 
> and you have big banks as clients. Shit like replace-by-fee and leading 
> the anti-scaling mob is for your clients, not Bitcoin. Get the fuck out.
> 
> Peter Todd - 8930511 Canada Ltd.
> 1214-1423 Mississauga Valley Blvd.
> Mississauga ON L5A 4A5
> Canada
> 
> https://www.ic.gc.ca/app/scr/cc/CorporationsCanada/fdrlCrpDtls.html?corpId=8930511
> 
> On 2015-05-26 00:10, Peter Todd wrote:
>> On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:
>>> CPFP also solves it just fine.
>>
>> CPFP is a significantly more expensive way of paying fees than RBF,
>> particularly for the use-case of defragmenting outputs, with cost
>> savings ranging from 30% to 90%
>>
>>
>> Case 1: CPFP vs. RBF for increasing the fee on a single tx
>> --
>>
>> Creating an spending a P2PKH output uses 34 bytes of txout, and 148
>> bytes of txin, 182 bytes total.
>>
>> Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to
>> Alice. This results in a 1in/2out transaction t1 that's 226 bytes in 
>> size.
>> I forget to click on the "priority fee" option, so it goes out with the
>> minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output,
>> creating a new transaction t2 that's 192 bytes in size. I want to pay
>> 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of
>> transaction fees.
>>
>> On the other hand, had I use RBF, my wallet would have simply
>> rebroadcast t1 with the change address decreased. The rules require you
>> to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the 
>> new
>> fee level, or 218uBTC of fees in total.
>>
>> Cost savings: 48%
>>
>>
>> Case 2: Paying multiple recipients in succession
>> 
>>
>> Suppose that after I pay Alice, I also decide to pay Bob for his hard
>> work demonstrating cryptographic protocols. I need to create a new
>> transaction t2 spending t1's change address. Normally t2 would be
>> another 226 bytes in size, resulting in 226uBTC additional fees.
>>
>> With RBF on the other hand I can simply double-spend t1 with a
>> transaction paying both Alice and Bob. This new transaction is 260 
>> bytes
>> in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth
>> consumed broadcasting it, resulting in an additional 36uBTC of fees.
>>
>> Cost savings: 84%
>>
>>
>> Case 3: Paying multiple recipients from a 2-of-3 multisig wallet
>> 
>>
>> The above situation gets even worse with multisig. t1 in the multisig
>> case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC
>> in fees. With RBF we rewrite t1 with an additional output, resulting in
>> a 399 byte transaction, with just 36uBTC in additional fees.
>>
>> Cost savings: 90%
>>
>>
>> Case 4: Dust defragmentation
>> 
>>
>> My wallet has a two transaction outputs that it wants to combine into
>> one for the purpose of UTXO defragmentation. It broadcasts transaction
>> t1 with two inputs and one output, size 340 bytes, paying zero fees.
>>
>> Prior to the transaction confirming I find I need to spend those funds
>> for a priority transaction at the 1mBTC/KB fee level. This transaction,
>> t2a, has one input and two outputs, 226 bytes in size. However it needs
>> to pay fees for both transactions at once, resulting in a combined 
>> total
>> fee of 556uBTC. If this situation happens frequently, defragmenting
>> UTXOs is likely to cost more in additional fees than it saves.
>>
>> With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374
>> bytes in size, paying 374uBTC. Even better, if one of the two inputs is
>> sufficiently large to cover my costs I can doublespend t1 with a
>> 1-in-2-out tx just 226 bytes in size, paying 226uBTC.
>>
>> Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF
>>   costs you more than you save
>>
>> --
>> One dashboard for servers and applications across 
>> Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance 

Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

[s7r]

Hello,

How will this exactly be safe against:
a) the malleability of the parent tx (2nd level malleability)
b) replays

If you strip just the scriptSig of the input(s), the txid(s) can still
be mutated (with higher probability before it gets confirmed).

If you strip both the scriptSig of the parent and the txid, nothing can
any longer be mutated but this is not safe against replays. This could
work if we were using only one scriptPubKey per tx. But this is not
enforced, and I don't think it's the proper way to do it.

Something similar can be achieved if you would use a combination of
flags from here:

https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md

But this has some issues too.

I've read your draft but didn't understand how exactly will this prevent
normal malleability as we know it, second level malleability and replays
as well as how will we do the transition into mapping the txes in the
blockchain to normalized txids. Looking forward to read more on this
topic. Thanks for the brainstorming ;)


On 5/13/2015 3:48 PM, Christian Decker wrote:
> Hi All,
> 
> I'd like to propose a BIP to normalize transaction IDs in order to
> address transaction malleability and facilitate higher level protocols.
> 
> The normalized transaction ID is an alias used in parallel to the
> current (legacy) transaction IDs to address outputs in transactions. It
> is calculated by removing (zeroing) the scriptSig before computing the
> hash, which ensures that only data whose integrity is also guaranteed by
> the signatures influences the hash. Thus if anything causes the
> normalized ID to change it automatically invalidates the signature. When
> validating a client supporting this BIP would use both the normalized tx
> ID as well as the legacy tx ID when validating transactions.
> 
> The detailed writeup can be found
> here: https://github.com/cdecker/bips/blob/normalized-txid/bip-00nn.mediawiki.
> 
> @gmaxwell: I'd like to request a BIP number, unless there is something
> really wrong with the proposal.
> 
> In addition to being a simple alternative that solves transaction
> malleability it also hugely simplifies higher level protocols. We can
> now use template transactions upon which sequences of transactions can
> be built before signing them.
> 
> I hesitated quite a while to propose it since it does require a hardfork
> (old clients would not find the prevTx identified by the normalized
> transaction ID and deem the spending transaction invalid), but it seems
> that hardforks are no longer the dreaded boogeyman nobody talks about.
> I left out the details of how the hardfork is to be done, as it does not
> really matter and we may have a good mechanism to apply a bunch of
> hardforks concurrently in the future.
> 
> I'm sure it'll take time to implement and upgrade, but I think it would
> be a nice addition to the functionality and would solve a long standing
> problem :-)
> 
> Please let me know what you think, the proposal is definitely not set in
> stone at this point and I'm sure we can improve it further.
> 
> Regards,
> Christian
> 
> 
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud 
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> 
> 
> 
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] 75%/95% threshold for transaction versions

[s7r]

Thank you all for your comments. The youtube video was indeed very
educative and nice to watch.

It's true that malleability is not the end of the world, but it is
annoying for contracts and micropayment channels, especially refunds
spending the fund tx before it is even in the blockchain, relying solely
on its txid.

BIP62 is good for preventing 3rd parties (non signers) to mutate txids,
but cannot do anything against 2nd parties (signers). I think we can
solve both by using NORMALIZEDTXID - wouldn't this be simpler and easier
to implement? Why are we talking about P3SH when we can just upgrade
P2SH to support additional OP codes? I saw that there have been talks
about a hard fork for increasing the block size, might as well take the
opportunity and fix this for good, by implementing BIP62, NORMALIZEDTXID
as well as BIP65. Couldn't all these be part of P2SH?

On 4/25/2015 6:40 PM, Stephen Morse wrote:
> Hi Gregory,
> 
> In particular not covering the ID allows for transaction replay which
> can result in monetary losses far more severe than any possible
> mishandling of malleability could result in. Byzantine attackers can
> costlessly replay your old transactions any time anyone reuses an
> address, even accidentally (which cannot be easily prevented since
> they can race).
> 
> 
> With the SIGHASH_WITHOUT_PREV_VALUE flag, signatures have to explicitly
> specify that they are to be signed without the previous UTXO's
> value/amount. This means that, at worst, replay attacks can send the
> money to the same place it was sent before (which in many cases is
> likely not be a loss of funds), and only if the amount sent to the
> reused address is the exact same as it was before. I don't think this is
> worse than an attacker being able to mutate their transaction and extort
> a merchant who accepts zero-conf transactions. Anyway, not signing the
> input ID wouldn't exactly be the norm, there would be a defined set of
> flags for standard use cases. Not signing the input TXID would only be
> used in specialized cases, such as setting up micropayment channels. 
>  
> 
> There are no free lunches;  the proposal linked to there is itself a
> game of wack-a-mole with assorted masking flags; 
> 
> 
> I agree that it is also a bit of wac-a-mole, but the defined space of
> issues is possibly more limited here. There are only X number of things
> that can be signed/not signed in a transaction, and the 'Build your own
> nHashType' proposal enables you to fully specify which of those are
> being signed. If you don't want to get burned by not fully signing your
> transactions, then don't use the non-standard sighash flags.
> 
> many of which we have
> no notion of if they're useful for any particular application(s); 
> 
> 
> A few of the flags, indeed, may not ever be useful. But we can't predict
> the future, and I think it's better to build in a more flexible solution
> now than to wish we had more flexible nHashTypes later.
> 
> To the original point of this thread, hopefully the suggested proposal
> won't be necessary as wallets will upgrade to use version 3 transactions
> and the rules associated with them over time. 
> 
> Best,
> Stephen
> 
> 
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud 
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> 
> 
> 
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] 75%/95% threshold for transaction versions

[s7r]

Understood. That is unfortunate, but not the end of the world. If you
could please give feedback also to these last comments / questions:

How far are we at this moment from BIP62? Can an user send a
non-malleable tx now, if enforces some additional rules?

As for the security of the system, it does not fully rely on txids being
non malleable, but see this quote from my previous email:

[QUOTE]
I am trying to build a bitcoin contract which will relay on 3 things:
- coinjoin / txes with inputs from multiple users which are signed by
all users after they are merged together (every user is sure his coins
will not be spent without the other users to spend anything, as per
agreed contract);
- pre-signed txes with nLockTime 'n' weeks. These txes will be signed
before the inputs being spent are broadcasted/confirmed, using the txid
provided by the user before broadcasting it. Malleability hurts here.
- P2SH

Another thing I would like to confirm, the 3 pieces of the bitcoin
protocol mentioned above will be supported in _any_ future transaction
version or block version, regardless what changes are made or features
added to bitcoin core? The contract needs to be built and left unchanged
for a very very long period of time...
[/END QUOTE]

Can you comment on the quote please?

So, basically transaction malleability could affect the system in the
way that a pre-signed tx which offers the insurance and which is sent to
the user before the user sends the coins (spending user's coins back to
him after a certain period of time) could be invalidated. The insurance
tx signature will still be good, but invalid overall since the input
(txid) being spent does not exist (was altered / modified). The coins
won't be stolen or lost, but a new tx needs to be signed with the
altered (new) txid, for the system to work.

So, an user creates a transaction TX1 sending the coins to the server
but does not broadcast it. Instead, he provides the txid of TX1 to the
server. Server generates another transaction TX2 which spends TX1 back
to the user, with an nLockTime. User checks and if everything ok
broadcasts TX1. In case the txid of TX1 will be altered/modified, TX2
will become invalid (since it will be spending an inexistent input), and
the server will need to re-create and sign TX2 with the new
(altered/modified) txid of TX1, as per agreed contract. Should the
server disappear after user broadcasts TX1 and before the
altered/modified txid of TX1 gets confirmed, user's coins are forever
locked. It is true that no third party can benefit from this type of
attack, only the user will result with coins locked, but it is something
which could be used by competition to make a service useless / annoying
/ too complicated or less safe to use.

How could I mitigate this?

Thanks you for your time and help.

On 4/17/2015 12:02 PM, Pieter Wuille wrote:
>> Anyone can alter the txid - more details needed. The number of altered
>> txids in practice is not so high in order to make us believe anyone can
>> do it easily. It is obvious that all current bitcoin transactions are
>> malleable, but not by anyone and not that easy. At least I like to
> think so.
> 
> Don't assume that because it does not (frequently) happen, that it
> cannot happen. Large amounts of malleated transactions have happened in
> the past. Especially if you build a system depends on non-malleability
> for its security, you may at some point have an attacker who has
> financial gain from malleation.
> 
>> >From your answer I understand that right now if I create a transaction
>> (tx1) and broadcast it, you can alter its txid at your will, without any
>> mining power and/or access to my private keys so I would end up not
>> recognizing my own transaction and probably my change too (if my systems
>> rely hardly on txid)?
> 
> In theory, yes, anyone can alter the txid without invalidating it,
> without mining power and without access to the sender's private keys.
> 
> All it requires is seeing a transaction on the network, doing a trivial
> modification to it, and rebroadcasting it quickly. If the modifies
> version gets mined, you're out of luck. Having mining power helps of course.
> 
> After BIP62, you will, as a sender, optionally be able to protect others
> from malleating. You're always able to re-sign yourself.
> 
> -- 
> Pieter
> 

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] 75%/95% threshold for transaction versions

[s7r]

On 4/16/2015 8:34 PM, Mark Friedenbach wrote:
> At this moment anyone can alter the txid. Assume transactions are 100%
> malleable.
> 

Anyone can alter the txid - more details needed. The number of altered
txids in practice is not so high in order to make us believe anyone can
do it easily. It is obvious that all current bitcoin transactions are
malleable, but not by anyone and not that easy. At least I like to think so.

>From your answer I understand that right now if I create a transaction
(tx1) and broadcast it, you can alter its txid at your will, without any
mining power and/or access to my private keys so I would end up not
recognizing my own transaction and probably my change too (if my systems
rely hardly on txid)?

> On Apr 16, 2015 9:13 AM, "s7r" mailto:s...@sky-ip.org>>
> wrote:
> 
> Hi Pieter,
> 
> Thanks for your reply. I agree. Allen has a good point in the previous
> email too, so the suggestion might not fix anything and complicate
> things.
> 
> The problem I am trying to solve is making all transactions
> non-malleable by default. I guess there is a very good reason why BIP62
> will not touch v1 anyway.
> 
> I am trying to build a bitcoin contract which will relay on 3 things:
> - coinjoin / txes with inputs from multiple users which are signed by
> all users after they are merged together (every user is sure his coins
> will not be spent without the other users to spend anything, as per
> agreed contract);
> - pre-signed txes with nLockTime 'n' weeks. These txes will be signed
> before the inputs being spent are broadcasted/confirmed, using the txid
> provided by the user before broadcasting it. Malleability hurts here.
> - P2SH
> 
> In simple terms, how malleable transactions really are in the network at
> this moment? Who can alter a txid without invalidating the tx? Just the
> parties who sign it? The miners? Anyone in the network? This is a little
> bit unclear to me.
> 
> Another thing I would like to confirm, the 3 pieces of the bitcoin
> protocol mentioned above will be supported in _any_ future transaction
> version or block version, regardless what changes are made or features
> added to bitcoin core? The contract needs to be built and left unchanged
> for a very very long period of time...
> 
> 
> On 4/16/2015 8:22 AM, Pieter Wuille wrote:
> >
> > On Apr 16, 2015 1:46 AM, "s7r"  <mailto:s...@sky-ip.org> <mailto:s...@sky-ip.org 
> <mailto:s...@sky-ip.org>>>
> > wrote:
> >> but for transaction versions? In simple terms, if > 75% from all the
> >> transactions in the latest 1000 blocks are version 'n', mark all
> >> previous transaction versions as non-standard and if > 95% from
> all the
> >> transactions in the latest 1000 blocks are version 'n' mark all
> previous
> >> transaction versions as invalid.
> >
> > What problem are you trying to solve?
> >
> > The reason why BIP62 (as specified, it is just a draft) does not
> make v1
> > transactions invalid is because it is opt-in. The creator of a
> > transaction needs to agree to protect it from malleability, and this
> > subjects him to extra rules in the creation.
> >
> > Forcing v3 transactions would require every piece of wallet
> software to
> > be changed.
> >
> > --
> > Pieter
> >
> 
> 
> --
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live
> exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
> event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> <mailto:Bitcoin-development@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] 75%/95% threshold for transaction versions

[s7r]

Hi Pieter,

Thanks for your reply. I agree. Allen has a good point in the previous
email too, so the suggestion might not fix anything and complicate things.

The problem I am trying to solve is making all transactions
non-malleable by default. I guess there is a very good reason why BIP62
will not touch v1 anyway.

I am trying to build a bitcoin contract which will relay on 3 things:
- coinjoin / txes with inputs from multiple users which are signed by
all users after they are merged together (every user is sure his coins
will not be spent without the other users to spend anything, as per
agreed contract);
- pre-signed txes with nLockTime 'n' weeks. These txes will be signed
before the inputs being spent are broadcasted/confirmed, using the txid
provided by the user before broadcasting it. Malleability hurts here.
- P2SH

In simple terms, how malleable transactions really are in the network at
this moment? Who can alter a txid without invalidating the tx? Just the
parties who sign it? The miners? Anyone in the network? This is a little
bit unclear to me.

Another thing I would like to confirm, the 3 pieces of the bitcoin
protocol mentioned above will be supported in _any_ future transaction
version or block version, regardless what changes are made or features
added to bitcoin core? The contract needs to be built and left unchanged
for a very very long period of time...


On 4/16/2015 8:22 AM, Pieter Wuille wrote:
> 
> On Apr 16, 2015 1:46 AM, "s7r" mailto:s...@sky-ip.org>>
> wrote:
>> but for transaction versions? In simple terms, if > 75% from all the
>> transactions in the latest 1000 blocks are version 'n', mark all
>> previous transaction versions as non-standard and if > 95% from all the
>> transactions in the latest 1000 blocks are version 'n' mark all previous
>> transaction versions as invalid.
> 
> What problem are you trying to solve?
> 
> The reason why BIP62 (as specified, it is just a draft) does not make v1
> transactions invalid is because it is opt-in. The creator of a
> transaction needs to agree to protect it from malleability, and this
> subjects him to extra rules in the creation.
> 
> Forcing v3 transactions would require every piece of wallet software to
> be changed.
> 
> -- 
> Pieter
> 

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] 75%/95% threshold for transaction versions

[s7r]

Hi,

Would it be wise to add a consensus rule like the one we have for blocks,

(if > 75% from last 1000 blocks are version 'n' mark version 'n' as
standard for blocks and if > 95% from the last 1000 blocks are version
'n' mark previous block versions as invalid)

but for transaction versions? In simple terms, if > 75% from all the
transactions in the latest 1000 blocks are version 'n', mark all
previous transaction versions as non-standard and if > 95% from all the
transactions in the latest 1000 blocks are version 'n' mark all previous
transaction versions as invalid.

At this moment, the standard in consensus is v1, but nothing is enforced
in the network related to transaction versions.

Regarding BIP62, as it can be read here [0] it is said that it requires
v2 transactions. It is also said that transaction version 2 will be
skipped and jump directly to v3, for an even version for transactions
and blocks (?). Might as well add the rule for invalidating previous
transaction versions if the majority updates - could this break anything
or affect functionality in any way?

BIP62 adds a newer transaction version which is optional and does not
mark previous v1 as non-standard or invalid. This means bitcoin core
will treat both v1 and v2/v3 transactions as standard and relay/mine
them with the same priority, regardless of the tx version?


Thanks.

[0]
https://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-dealing-with-malleability-has-been-implemented

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Address Expiration to Prevent Reuse

[s7r]

This should not be enforced by default. There are some use cases where
address re-use is justified (a donation address spread on multiple
static pages or even printed on papers/books?). For example, I offer
some services on the internet for free, and I only have a bitcoin
address for donations which is posted everywhere. Obviously this could
possibly harm privacy, but not everyone who uses bitcoin wants to keep
all transactions private. To the contrary, there are accounting cases
when you need to archive all keys, hashes of transactions and
everything (for example when using btc inside a company which is
required by law to keep accounting registries).

I know it's not recommended to use the same pubkey more than once, but
the protocol was not designed this way. Enforcing something as
described in this topic will undermine an user's rights to re-use his
addresses, if a certain situation requires it.

On 3/26/2015 11:44 PM, Gregory Maxwell wrote:
> On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding  
> wrote:
>> I should have been clearer that the motivation for address 
>> expiration is to reduce the rate of increase of the massive pile 
>> of bitcoin addresses out there which have to be monitored
>> forever for future payments.  It could make a significant dent
>> if something like this worked, and were used by default someday.
> 
> Great, that can be accomplished by simply encoding an expiration 
> into the address people are using and specifying that clients 
> enforce it.
> 
> --

>
>
> 
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
> by Intel and developed in partnership with Slashdot Media, is your 
> hub for all things parallel software development, from weekly 
> thought leadership blogs to news, videos, case studies, tutorials 
> and more. Take a look and join the conversation now. 
> http://goparallel.sourceforge.net/ 
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] SPV clients and relaying double spends

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 9/26/2014 5:16 AM, Matt Whitlock wrote:
> Probably the first double-spend attempt (i.e., the second 
> transaction to spend the same output(s) as another tx already in 
> the mempool) would still need to be relayed. A simple
> "double-spend alert" wouldn't work because it could be forged. But
> after there have been two attempts to spend the same output, no
> further transactions spending that same output should be relayed,
> in order to prevent flooding the network.
> 
This sounds rational - is this already implemented nowadays or *SHOULD
BE* implemented to prevent this attack type in the future?
> 
> On Thursday, 25 September 2014, at 7:12 pm, Aaron Voisine wrote:
>> Something like that would be a great help for SPV clients that 
>> can't detect double spends on their own. (still limited of
>> course to sybil attack concerns)
>> 
>> Aaron Voisine breadwallet.com
>> 
>> 
>> On Thu, Sep 25, 2014 at 7:07 PM, Matt Whitlock 
>>  wrote:
>>> What's to stop an attacker from broadcasting millions of
>>> spends of the same output(s) and overwhelming nodes with
>>> slower connections? Might it be a better strategy not to relay
>>> the actual transactions (after the first) but rather only
>>> propagate (once) some kind of double-spend alert?
>>> 
>>> 
>>> On Thursday, 25 September 2014, at 7:02 pm, Aaron Voisine 
>>> wrote:
>>>> There was some discussion of having nodes relay
>>>> double-spends in order to alert the network about double
>>>> spend attempts.
>>>> 
>>>> A lot more users will be using SPV wallets in the future,
>>>> and one of the techniques SPV clients use to judge how likely
>>>> a transaction is to be confirmed is if it propagates across
>>>> the network. I wonder if and when double-spend relaying is 
>>>> introduced, if nodes should also send BIP61 reject messages 
>>>> or something along those lines to indicate which
>>>> transactions those nodes believe to be invalid, but are
>>>> relaying anyway.
>>>> 
>>>> This would be subject to sybil attacks, as is monitoring 
>>>> propagation, however it does still increase the cost of 
>>>> performing a 0 confirmation double spend attack on an SPV 
>>>> client above just relaying double-spends without indicating 
>>>> if a node believes the transaction to be valid.
>>>> 
>>>> Aaron Voisine breadwallet.com
>>> 
> 
> --
>
>
> 
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS 
> Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download 
> White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with 
> EventLog Analyzer 
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>
>
> 
___
> Bitcoin-development mailing list 
> Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUJZPVAAoJEIN/pSyBJlsRfgoIAI4x4qITdCDyYx/I1+z4eGz3
u7zDbVGQEPsUlrgEZLf503TNUIKmEgYQvgQDGEdOQk615XlkrTJeqt5oLh9DVJKj
TaXRqKgBp4iNd6BIIs1gKl0CzmH9sJ7U9ojhTS5aV7ZUhinO0WZlgISYaBZ3t9Kw
t//jb8QNLqISOeotiO9A2jb06UVRf9Gh0FUSBYTJ/st0UvLWt286zT+4XOaeVI/c
9I9nkTsd/jdw1Eorfcd5T8iHBORcdn9g+5+UpuXVq7d3KA5FA6oetzBVHgUfTMjF
q9LAe0W9IUVSiRj+wWvADzlxeUwWjsHnJDxdGihBg/g+k6SfPnOAxEC1UjCH+OU=
=kaIX
-END PGP SIGNATURE-

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/28/2014 5:08 PM, Gregory Maxwell wrote:
> On Mon, Jul 28, 2014 at 5:31 AM, Robert McKay 
> wrote:
>> I don't think Sybil attack is the right term for this.. there is
>> only one IP address.. one "identity".
> 
> The bitcoin protocol is more or less identityless. It's using up
> lots of network capacity, "number of sockets" is as pretty close as
> you get.
> 
>> I'm not even sure that this behaviour can be considered abuse..
>> it's pretty much following the rules and maybe even improving the
>> transaction and block propagation.
> 
> It isn't relaying transactions or blocks as far as anyone with a 
> connection to it can tell.
> 
> and sure, probably not much to worry about— people have been
> running spy nodes for a long time, at least that much is not new.
> 
> --
>
> 
Infragistics Professional
> Build stunning WinForms apps today! Reboot your WinForms
> applications with our WinForms controls. Build a bridge from your
> legacy apps to the future. 
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>
> 
___
> Bitcoin-development mailing list 
> Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
gmaxwell - I wanted to ask you a non-expert question. Let's say I use
my bitcoin-qt on my laptop with Tor, and send some BTC or receive
some, what can my Tor exit node see / do / harm? He can alter the
content, by modifying and transmitting invalid transactions to the
network but this will have no effect on me, e.g. can't steal coins or
send them on my behalf or intercept my payments, right? It's not clear
for me what data would such a node see? Why would you spend money to
setup a spy node for this what relevant data can it give you?

- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJT1nafAAoJEIN/pSyBJlsR8GYIAL9LkZvPbKjJ6cUxlC4yRKay
YUumAafCKYMvp8Ywvz3CWpC4Gncn+v29hhJu/Nc0wSItAnf4suwrAFtBAwAYlUx8
a1J6S1hgGXCBWDZcGHDc1Xt2lLzvijDcilSZfQWXnAdoEaZyln/7Kn+o/fFcXG6h
DUkSCSe9M3tN/tZBcZrhBXTENhoJ6MZldcgey6Ky0qLkmI3GCd0MhM+D15xl1LkT
6IS2r2y0RUOxkbg/SuSzFS8vnNTTWmZpbECo3Qq98W41X0M3ZtjOlaByPZXFX5K9
+HUeiptV9zukSdIRcuGH1PUQvU9nk+G1rFKr0dXu4oPvAUxqyw9uCTFgHXczuQY=
=gw3W
-END PGP SIGNATURE-

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/28/2014 6:44 AM, Gregory Maxwell wrote:
> On Sun, Jul 27, 2014 at 7:54 PM, m...@bitwatch.co
>  wrote:
>> These website list Tor nodes by bandwidth:
>> 
>> http://torstatus.blutmagie.de/index.php 
>> https://torstatus.rueckgr.at/index.php?SR=Bandwidth&SO=Desc
>> 
>> And the details reveal it's a port 8333 only exit node: 
>> http://torstatus.blutmagie.de/router_detail.php?FP=0d6d2caafbb32ba85ee5162395f610ae42930124
>
>> 
> As I pointed out above, — it isn't really.  Without the exit flag,
> I believe no tor node will select it to exit 8333 unless manually 
> configured. (someone following tor more closely than I could
> correct if I'm wrong here)
> 
> 
>> blockchain.info has some records about the related IP going back
>> to the end of this May:
>> 
>> https://blockchain.info/ip-address/5.9.93.101?offset=300
> 
> dsnrk and mr_burdell on freenode show that the bitnodes crawler
> showed it accepting _inbound_ bitcoin connections 2-3 weeks ago,
> though it doesn't now.
> 
> Fits a pattern of someone running a bitcoin node widely connecting
> to everyone it can on IPv4 in order to try to deanonymize people,
> and also running a tor exit (and locally intercepting 8333 there),
> but I suspect the tor exit part is not actually working— though
> they're trying to get it working by accepting huge amounts of relay
> bandwidth.
> 
> I'm trying to manually exit through it so I can see if its 
> intercepting the connections, but I seem to not be able.
> 
> Some other data from the hosts its connecting out to proves that
> its lying about what software its running (I'm hesitant to just say
> how I can be sure of that, since doing so just tells someone how to
> do a more faithful emulation; so that that for whatever its
> worth).
> 
> --
>
> 
Infragistics Professional
> Build stunning WinForms apps today! Reboot your WinForms
> applications with our WinForms controls. Build a bridge from your
> legacy apps to the future. 
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>
> 
___
> Bitcoin-development mailing list 
> Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 


The thing is, if it doesn't have the exit flag it cannot generate lots
of traffic from real good-intended clients, because it's quite hard
for clients to choose this Node as ËXIT in their path if it doesn't
have the exit flag. So the traffic comes from clients who specifically
added "ExitNode " in their torrc and only use that Tor
instance for Bitcoin. So, someone build this custom Tor node for
themselves only, for plausible den. A pool could be the cause as it
was earlier discussed here...

The thing is I cannot find this node on atlas, globe or blutmagie can
you please provide fingerprint and IP address again? So I may ignore
it on my relays and talk to some people about it?
- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJT1jXjAAoJEIN/pSyBJlsRjqgIAIFxHcypU6KUaNdSvESADilM
kFiitf00f4Uy9tBwSLVPQw+I2L1EmMiCNvqG4RRjV2+/PS696HCz0Jt0gVaGlMPl
DHQSHsozx3BaXi5PpGeLl7uSNLHlEdytytZ8xb08I4IuqcNNHzvxnou7gXapeezC
PuSABsxVLpDn+OP7QLRy/PlL948Yfgbxwb9dcn+lUdgDlByxxhMmOrk+o/VdGfnh
cL/C+qgpuJiI/wrQridtBmxU8h7Z6TKKua7eWONyg6MrnjwWuZTumhAGO2H4X1Na
IZiCmhEwtxb97TMG0EvgcZTeRzfzoddTnOe6ZEsiqOZ7qPNjFJ2i8RoSOI3gUCQ=
=t3Mb
-END PGP SIGNATURE-

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development